afin de favoriser le passage d’applications communautaires en officielles, je propose de mettre en place quelques règles, tirées des YEP qui sont en cours de rédaction.
Nous avions pour le moment une initiative de Bram, dont je propose de reprendre les principaux aspects.
Ce document n’a pas vocation à remplacer les YEP, qui devrait devenir notre grille d’évaluation officielle. Mais à s’y substituer le temps de leur finalisation pour pouvoir dés maintenant valider des applications.
J’ai relevé quelques règles des YEP qui me semble être tout à fait applicable à une app officielle.
Maintenir son paquet (YEP 1.4)
Pour être officielle, le package doit être maintenu. Donc le packageur proposant son app doit s’engager à la maintenir dans le temps. Ou trouver un remplaçant si il ne peux pas la maintenir.
En effet, on ne peux pas se permettre d’avoir des apps officielles qui tombent en désuétude.
Se tenir informé (YEP 1.6)
Suivre le forum et la ML pour rester informé des nouvelles pratiques ou des infos importantes.
Passer avec succès tout les tests de Package check et de Package linter (YEP 1.8)
L’étape qui fait mal ! Si un package ne passe pas ces tests, elle est potentiellement non fonctionnelle sur certaines configurations.
Pour package linter, il y a quelques faux positifs, et globalement ça ne casse pas le package. Donc je pense que c’est à voir au cas par cas.
Documenter son app (YEP 1.9)
Renseigner le readme et une page de doc le cas échéant. L’application doit être facilement utilisable.
Et commenter son code pour faciliter la relecture et le débugage.
Gérer les erreurs (YEP 2.4)
Prendre en compte les erreurs du script, que ce soit avec trap ou set -e ou les erreurs plus commune comme des variables vide, un dossier déjà utilisé etc.
Ne pas embarquer les sources
Ne pas embarquer les sources en tarball. Pour le reste… C’est en cours…
Vérifier l’intégrité de la source (YEP 3.3)
Même discussion que la règle précédente.
Modifier proprement les config système (YEP 2.8)
Utiliser les .d autant que possible, ne pas toucher aux fichiers système directement quand c’est possible. Limiter l’impact sur le système globalement, pour être propre à la suppression.
Tout effacer à la suppression (YEP 2.9)
Un package supprimé ne doit pas laissé de résidus, sauf les fichiers personnels de l’utilisateur le cas échéant. Et les dépendances des paquets, car supprimer les paquets installés pourrait impacter d’autres packages.
Configurer log-rotate le cas échéant (YEP 2.10)
En cas de configuration d’un log, il faut utiliser log-rotate pour éviter de saturer le système avec des logs gonflant sans limite.
Utiliser $app (YEP 2.11)
Utiliser la variable $app au lieu du nom du package pour faciliter la reprise du code.
Utiliser les helpers (YEP 2.12)
Utiliser au maximum les helpers mis à disposition.
Tester sur ARM, x86 et x64 (YEP 2.16)
Le package doit être testé sur toutes les architectures susceptibles d’être rencontrées sur YunoHost.
Je vais me pencher sur la location d’un serveur ARM sur scaleway pour répondre à ce besoin.
Tester la mise à jour depuis une version précédente (YEP 2.17)
Il est essentiel qu’une mise à jour depuis une ancienne version ne casse pas l’application déjà installée. Ceci n’est pas vérifié par Package check, il faut le tester manuellement.
Intégrer la tuile YNH (YEP 2.18.5)
Intégrer la tuile YNH qui apparaît en bas à droite et qui permet de revenir rapidement au portail. C’est juste 2-3 lignes dans la conf nginx.
SSO et ldap (YEP 4.2)
Dans la mesure du possible, l’app devrait être configurée pour utiliser ldap pour ses utilisateurs, et http auth pour la connexion depuis le portail. Tout en permettant l’ajout d’utilisateurs et la connexion sans le portail (si l’app est publique)
Dans la mesure du possible, car certaines app ne le permettent pas…
Utiliser les hooks (YEP 4.5)
Utiliser les hooks appropriés, le plus souvent la création d’user. Si c’est applicable et justifié, en général c’est juste un compte utilisateur sur l’app, ce qui sera pris en charge par ldap.
multi-instance (YEP 4.6)
Favoriser l’installation multi-instance si c’est possible.
Avoir tout les scripts évidemment, upgrade, backup et restore également. Mais les scripts de test le vérifie. (YEP 4.3-4.4)
Installer à la racine et sur un chemin. (YEP 2.18.2-2.18.3-2.18.4)
Lorsque l’application le permet, elle doit être le plus flexible possible pour l’utilisateur final.
Utiliser un port variable. (YEP 3.2)
Le cas échéant, vérifier la disponibilité du port avant de l’ouvrir et en trouver un autre
Tout ceci est à valider ensemble.
Et a rédiger un peu mieux peut-être, quoi qu’il en soit, un packageur devra être accompagné dans cette démarche.
Et pour éviter un enlisement Décision stantard, date de clôture fixée au 27 décembre.
Comme ça, bonne résolution pour la nouvelle année, on passe plein d’app en officielles!
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…
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.
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.
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
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
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.
@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.
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 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?
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 ?
?