Rédaction de règles pour passer une app en officielle

J’ajoute de commenter son code, parce que ça me semble vraiment ESSENTIEL de commenter son code pour la relecture.
Je suis actuellement en train d’éplucher le code de l’install de teampass, et je remercie vraiment le dev d’avoir commenté son code. C’est vraiment appréciable!

Et c’est une habitude qu’on a pas trop chez YunoHost…

D’accord avec la proposition ci-dessus ?

  • oui
  • non

0 voters

Salut, je pense qu’il faudrait travailler sur le document YEP et n’utiliser que celui-ci.
On pourrait commencer en effet comme tu le proposes par s’accorder sur les YEP nécessaires au statut officiel. Puis les utiliser même si toutes les YEPs ne sont pas encore définitives.

Extraire les YEP temporairement je pense que ca peut freiner le travail global sur les YEP non ?
Si Maniack tu es d’accord, peut-être peux-tu faire une PR avec tes modifications de YEP officielles sur le git et on en discute là ? Ce sera plus facile

D’ailleurs peut-être pourrais-t-on mettre cette page de YEP ailleurs temporairement afin d’ouvrir des issues comme pour ynh orga ?

L’idée était double, d’une part avancer sur la validation d’apps officielles, et d’autre part ne pas interférer dans le travail de ljf pour ne pas casser la cohérence du style de rédaction.
En attendant de savoir si il veux un coup de main pour la rédaction, je préfère ne pas interférer.

Après globalement, j’ai repris certaines YEP sans vraiment en changer le fond.

Et si on me dit déjà que ces règles sont peut-être trop dure pour les packageurs, prendre l’ensemble des YEP va être encore pire! D’où la nécessité d’en sélectionner quelques unes qui reflètent le minimum requis.

Qu’en pensez-vous?

Selon moi c’est juste une grille de lecture différente (un autre “tri” du tableau des YEP) selon l’essentialité, ou la simplicité de mise en oeuvre, ou l’objectif (officiel ou non). Mais au fond l’objectif est le même et donc la réflexion pourrait se faire aussi sur les YEP ?

Concernant le contenu suggéré je dois regarder ça à tête reposée à coté des YEP pour comparer ce qui a été enlevé / rajouté.
Ce serait éventuellement plus facile avec issues sur le gît mais on peut faire ça sur le forum ici ou dans un autre fil ? (Discuter des yep)

Oui c’est ça, c’est juste une grille de lecture des YEP adaptée à l’idée de commencer à valider des apps.
Et à terme, l’idée est bien de n’avoir que les YEP.

Tu as déjà ouvert un fil de discussion ici au sujet des YEP.

Selon le contenu des discussions, elles peuvent avoir lieux ici pour l’ouverture. Mais globalement, c’est plus pratique sur github puisque ça nous permet de faire des PR directement.

Mais je suis gêné à l’idée d’avancer sur les YEP sans ljf, puisque c’est lui qui les a initiés et qui les rédige.
D’où l’idée d’en relever quelques unes pour avancer sur les apps officielles.

Pour rappel, cette décision doit être close demain.

Il nous manque 2 avis positifs pour la clore.
@scith, la discussion n’est pas close. Si tu es contre, n’hésite pas à le dire.

J’ai pas trop le courage en ce moment de me plonger là dedans, mais je ne sais pas si c’est vraiment la bonne période pour clore cette décision, surtout avec aussi peut de contribution et discussion alors que ça me semble assez important :confused:

J’ai bien conscience de ne pas trop aider/probablement générer des frustrations en disant ça mais j’aimerai bien avoir l’avis de @opi et @juju sur cette question.

En tout cas de ce que j’ai relu ça me semble assez pertinant (pas donable en l’état à quelqu’un de motivé par contre, je pense que ça doit être rédiger sur la forme d’un guide motivant et encourageant).

En tout cas merci du temps que tu investies sur cette question fort importante :slight_smile:

1 Like

En l’état la décision ne sera pas close, en l’absence d’un nombre d’avis suffisants.
Je prend toutefois ta remarque comme une demande de report, ce qui décale donc la date de clôture au 3 janvier.

Oui, c’est frustrant d’un certaine manière, surtout au regard des apps en attente d’officialisation. Mais la question est importante et mérite une décision réfléchie.

La grille de validation publiée en début de topic est à l’usage de cette discussion avant tout. A terme, je pense, qu’à l’instar des YEP, cette grille de validation doit être à double lecture. Une lecture simple et rapide pour les membres du groupe, chargés de valider chaque YEP, et une lecture détaillée et accompagnée pour les packageurs souhaitant s’y conformer.

Moi le premier, j’ai éludé de nombreuses règles indiquée dans la doc par manque de documentation sur ce qui était attendu.

Je préférerais personnellement qu’on travaille tous ensemble sur les yep (si ljf est d’accord) pour éviter de faire le travail en double.
Puis quand on est d’accord sur les yep (sur lesquelles on peut éventuellement rajouter des priorités comme proposé ici) on peut extraire les prioritaires dans la doc plus lisible citée ici ?
Autant partir sur de bonnes bases plutôt qu’un prototype qui fera peut être accepter des apps vite fait qui devront être renforcées ensuite.

Sinon pour le contenu
2.9-2.12 ne me semblent pas essentielles à préciser (mais seront vérifiées de toutes manières)
3.3 peut fusionner avec le précédent (pas dans les yep, ici en textuel)

En fait beaucoup de yep se retrouvent ou pourraient se retrouver dans linter et package_check non ? ($app, helpers, erreurs, source, …) Pour une procédure simplifiée on pourrait dire : passe linter et package_check (cf YEP) et quelques autres trucs (s’engager à maintenir,…). Pour améliorer vos chances de rendre votre app officielle, cf YEP ?

@scith @Maniack_Crudelis
Je suis d’accord pour que d’autres personnes rédigent les YEP si elles ont le temps.
Pour ma part, je ne pourrais pas le faire en 2016.

Oui dans l’absolu les YEP devrait être vérifiées automatiquement.

@scith, si j’ai bien compris, en somme les propositions au début du topic te conviennent sur le fond, mais tu préférerais que le travail soit directement tiré des YEP, sans modifications.

L’usage des YEP pour le moment me pose 2 problèmes:

  • L’idée est de commencer à valider des apps pour stimuler le packaging, et les YEP ne sont pas terminées et nécessitent encore de nombreuses discussions.
  • En l’état, je pense qu’aucune app ne respecte complètement les YEP, et bon nombre de packageurs ne seront sans doute pas capable de toute les respecter.

Toutefois, nous pouvons reprendre les YEP sélectionnées précédemment et les détailler sur github pour ne pas faire le travail en double et préciser lesquels sont essentielles pour passer en officiel.

Surtout n’oublions pas l’idée de départ, l’intérêt de la manoeuvre est de stimuler le packaging en passant en officiel bon nombre d’application qui le mérite.
Car les YEP vont prendre encore pas mal de temps je pense.
Et si on jette un coup d’oeil au CI, on remarque rapidement qu’une seule app officielle passe correctement les tests…

Ne soyons pas trop rigide, et présentons une pente ascendante plutôt qu’un mur infranchissable.

Merci ljf :wink:

Voilà selon moi le minimum pour l’officiel (sachant que comme vous dites linter et package_check ont vocation a être complétés, donc en demandant de passer ces 2 tests on devrait déjà couvrir pas mal)

?

C’est radicale comme allègement!
Par rapport à ma proposition tu retires

  • Se tenir informé (YEP 1.6)
    Pour une app officielle ça me gène un peu, car cette YEP me semble directement liée à la 1.4. Si le mainteneur ne suit pas l’évolution de son package, il deviendra obsolète et d’autres devront s’occuper de le maintenir à sa place.

  • Documenter son app (YEP 1.9)
    La page de doc me semble pas essentielle, le readme est un plus.
    Par contre j’insiste sur la lisibilité du code, car une app officielle sera tôt ou tard modifiée par un autre packageur que le mainteneur.

  • Gérer les erreurs (YEP 2.4)
    Ce n’est pris en charge ni par package linter ni par package check. Et c’est potentiellement ravageur pour un serveur de prod en cas d’erreur!

  • Ne pas embarquer les sources

  • Vérifier l’intégrité de la source (YEP 3.3)
    C’est pas indispensable, c’est mieux mais pas indispensable à mon avis.

  • Modifier proprement les config système (YEP 2.8)
    Personnellement, je déteste que des résidus restent après une installation. Et pour moi, ça devrait être fait avant même de passer officiel.
    Mais c’est un avis personnel.

  • Tout effacer à la suppression (YEP 2.9)
    Pareil que précédemment.

  • Configurer log-rotate le cas échéant (YEP 2.10)
    C’est pas primordial, mais il faudrait veiller à ne pas saturer des serveurs à cause de logs énorme.

  • Utiliser $app (YEP 2.11)
    Pas indispensable mais mieux. On peut l’enlever.

  • Utiliser les helpers (YEP 2.12)
    Linter ne laissera pas passer, donc admettons.

  • Tester la mise à jour depuis une version précédente (YEP 2.17)
    Ça me semble indispensable pour ne pas casser les apps des utilisateurs.

  • Utiliser les hooks (YEP 4.5)
    Oui, admettons.

  • multi-instance (YEP 4.6)
    De même.

Mais bon, ça baisse drastiquement la qualité des apps…

Certes mais c’est le principe du minimum :slight_smile: plus on coche de yep, meilleure est la qualité. Pour moi le premier saut qualitatif c’est ton package_check (que ne passent pas bcp d’apps officielles). Il permet d’avoir une base solide il me semble (et inclut linter).
Puis en brodant autour de ca, ldap ou gestion automatisée d’utilisateurs/sso/tuile et maintenance au minimum. Après ça n’empêche pas de freiner une app qui coche le minimum mais représente un risque sur d’autres points réclamant améliorations non?

Se tenir informé mea culpa j’avais mal compris. Je pensais que c’était se tenir informé de l’évolution de ynh, mais en fait c’est de celle de son app c’est ça ? Oui c’est essentiel je trouve aussi (mais textuellement peut être mis avec 1.4). Par ex on voit que des que own/nextcloud tarde a être maj, les utilisateurs font des rustines.

Gestion des erreurs : peut on le rajouter vite fait sur linter ? (Détecté si trap ou set en début de script) ?

Tester les majs : textuellement avec la maintenance. On peut pas vraiment utiliser ca pour passer une app officielle. C’est plus une profession de foi

2.8 2.9 2.10 j’avais enlevé parce-que comme les hooks ça ne s’applique pas à toutes les apps. On peut vérifier au cas par cas?

Merci

Il faut voir avec @Moul pour ça. Mais c’est pas forcément évident à détecter avec l’usage de fonctions.

Donc si j’ai bien suivi, on garderait les YEP 1.4 - 1.6 - 1.8 - 1.9 - 2.4 - 2.16 - 2.18.5 - 4.2

2.8 et 2.9, j’insiste quand même. si ça casse des système, ça craint.

Moi ca me va :slight_smile:

N’arrivant pas à dormir, je repensais à une discussion intéressante qu’on avait eu à une réunion : l’idée de donner des “niveaux” de qualité aux applications suivant tout une liste de critères.

Je pense que ça permettrait de donner à la fois une indication visuelle de la qualité d’une app à nos utilisateurices et également un chemin à suivre bien plus progressif que juste “pas assez bon” et “assez bon” qui devrait être bien plus motivant. Je pense également que ça permettrait de combiner les divergences de point de vue quand au niveau d’exigence attendu, il faudra juste décidé à quel niveau une app peut devenir officielle.

Pour que ça soit plus concret, voici une série de niveau totalement improvisé là tout de suite (donc à modifier):

  • niveau 0 : l’app ne marche pas et ne s’install pas (== broken)
  • niveau 1 : l’app marche, s’install et se retire (mais des exceptions sont possible, par exemple ne peut s’installer que sur “/”)
  • niveau 2 : pareil mais sans exceptions
  • niveau 3 : l’app supporte les upgrades
  • niveau 4: intégration ssowat/ldap (si nécessaire)
  • niveau 5 : aucune erreur dans package_linter
  • niveau 6 : backup/restore
  • niveau 7 : aucune erreur dans package_check
  • niveau 8 : l’app est parfaite

J’ai bien dit que c’était fait à la va-vite au pif pour donner un exemple :stuck_out_tongue: ?

2 Likes

Excellente idée Bram !
Nous en avions déjà parlé en effet, mais jamais concrétisé. L’usage de package linter (bien qu’il lui manque des niveaux d’erreurs) et de package check ainsi que les YEP peuvent nous permettre de mettre en place cette idée.

C’est, à mon avis, très motivant et un bon levier d’améliorations des apps car ça donne un objectif et une forme de récompense par le niveau atteint.

Par contre, ça me semble une idée à mettre en place avant de passer des apps officielles, ce qui éloigne d’autant plus cela. Mais c’est une très bonne idée.