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.
Je trouve aussi l’idée très bonne, et l’on pourrait réordonner les exigences des différents niveaux, afin qu’une app passe officielle à partir (par exemple) d’un niveau de maturité 5 ou 6… ? On laisserait par exemple le sans-faute à package_linter, package_check, et l’intégration SSO au dessus du niveau requis. Du coup, on pourrait trouver un compromis pour passer plus rapidement des apps en officielles…
Après, pour relativiser, ça fait depuis … le début en fait qu’il y a pas de procédure pour passer une application en officielle, c’est une frustration qui est là depuis longtemps et que beaucoup de personnes ont.
Je pense que rien ne nous empêche, si on le veut, de proposer une app qu’on veut vraiment voir devenir officiel à un vote simple du groupe apps tout en travaillant au parallèle à cette histoire de niveaux pour prendre le temps de bien faire ça. Comme ça on ne bloque pas les apps qu’on veut voir devenir officielle (je pense à Nextcloud entre autre).
J’ai vraiment fait un exemple de niveau au pif avec ce qui me passait par la tête. J’avoue me sentir moyennement au bon endroit (niveau implication dans le packaging d’apps) pour vraiment faire une première bonne proposition pertinente. Si on me demande je peux y réfléchir mais je pense que pas mal d’autres personnes sont bien mieux placé que moi pour ça.
Après s’il faut le faire pour débloquer la situation je le ferai.
Oui nextcloud, il faudrait vraiment la passer en officielle.
Mais j’hésite toujours entre attendre des réponses de Jérôme et faire le boulot pour avancer.
Et vu l’état des apps officielles actuelles, on sera plus prêt de la vérité avec Nextcloud…
Pour package check, je pense que les niveaux doivent intégrer les différents tests proposés, certains sont moins important que d’autres.
J’ai pas mal de truc sur le feu, mais ça me dit bien de réfléchir à ces niveaux.
Une proposition de niveaux pour les apps:
###Niveau 0
L’application ne s’installe pas ou ne fonctionne pas après installation.
###Niveau 1
L’application s’installe et se désinstalle correctement. Mais des exceptions sont possibles, par exemple l’installation sur “/” n’est pas assurée.
###Niveau 2
L’application s’installe et se désinstalle dans toutes les configurations communes.
Installation en sous-dossier.
Installation à la racine d’un domaine ou d’un sous-domaine.
Installation privée (sécurisée par le SSO).
Installation publique.
Installation multi-instance.
Désinstallation dans les mêmes circonstances
Dans les limites permises par l’application
###Niveau 3
L’application supporte l’upgrade depuis une ancienne version du package.
###Niveau 4
L’application prend en charge les utilisateurs via la base ldap de Yunohost.
Et les utilisateurs se connectent en HTTP AUTH depuis le portail SSO.
###Niveau 5
Aucune erreur dans package_linter.
(En écartant les éventuels faux positifs)
###Niveau 6
L’application peut-être sauvegardée et restaurée sans erreurs sur la même machine ou une autre.
###Niveau 7
Aucune erreur dans package check.
###Niveau 8
L’application respecte toutes les YEP recommandées.
###Niveau 9
L’application respecte toutes les YEP optionnelles.
###Niveau 10
L’application est jugée parfaite.
Les niveaux 0 à 3 peuvent être certifiés par Package check.
Les niveaux 5, 6 et 7 peuvent être certifiés aussi, mais aussi sans l’assurance que le niveau 4 est validé.
Les niveaux 4, 8, 9 et 10 implique une vérification manuelle de notre part.
Et, j’oubliais l’essentiel !!!
Je pense que le niveau officiel peux être placé au niveau 6.
Il faudra par contre faire gaffe avec ce genre de “souplesse” : je ne sais pas comment l’officialisation des niveaux aura lieu et quel sera le média d’échange, mais il faudra que tout point non respecté soit justifié (pour éviter dans le cas présent des “boaf, c’était plus compliqué, je l’ai pas fait”).
Il y a forcément une intervention humaine dans la chaine, comme dit précédemment.
Et pour passer en officiel au moins, ce sera vérifié en profondeur.
Après pour les communautaires, c’est d’avantage selon la bonne foi du packageur et de ceux qui mettront le nez dedans.
Quid de la sécurisation pour passer en officiel ? (ou simplement pour une certain niveau)
Par exemple une application avec des paramètres par défaut peu sûrs (type l’application mise en public qui ne chiffre pas tel ou tel truc, qui laisse une faille potentielle, …).
De la même manière c’est une relecture attentive du code qui devrait permettre de vérifier ce genre de choses. Bien qu’on soit pas infaillibles sur la sécurité (moi en tout cas c’est sûr)
Pour un passage en officiel, on relira toujours le code.
Et j’insisterais jamais assez sur l’importance de commenter son putain de code !!! (Je sens déjà venir les nombreuses relecture de code non commenté…)
Avant de voter (question de syntaxe surtout, pour pas énerver le Bram), donnons tous notre avis
Dans la mesure où c’est une question déjà traitée et qu’on ne fait en quelque sorte que proposer une solution.
Je vous propose une prolongation d’une semaine de cette décision pour inclure les niveaux et valider cette forme pour valider les officielles.
Soit clôture de décision au 6 janvier au lieu du 3. Toujours en décision standard.
Afin d’avancer sur la question, la clôture est prévue pour ce vendredi 6.
Cette décision concerne donc la validation des applications officielles, par l’intermédiaire des niveaux d’applications proposés plus haut.
Je vous invite donc à vous exprimer sur le sujet.
NB:
L’application des “niveaux” implique une modification des listes officielles et communautaires pour l’afficher. Et je n’ai personnellement pas les éléments pour faire cette modification.
J’aimerais ajouter dans les niveaux, en particulier pour les apps officielles la prise en charge des différentes architectures processeurs. Mais avant cela, il est nécessaire de permettre au CI de tester sur différentes architectures. Donc chaque chose en son temps…
Sachant que ça ne sera pas forcément possible de supporter toutes les architectures (ou en tout cas les principales). Exemple: Jitsi n’a pas le librairie pour plateforme ARM.
(mais je suppose qu’une fois de plus la condition est là “si applicable” - je préfère le rappeler au cas où)
J’ajouterais quand même une gestion clair des sources de l’app. En gros il faut qu’on puisse savoir si les sources ont été modifiées et si oui quoi. Je sais que c’est une question de sécurité qui peut sembler secondaire face à l’aspect fonctionnel, mais comme ça a déjà été dit la plupart des failles de yunohost viennent sans doute des apps.
Peut-on passer en officiel une app sans support ARM étant donné le nombre potentiel de briques en circulation ? En l’etat je ne suis pas sur … C’est dommage de se voir propoposer une app officielle puis lors de l’installation se la faire refuser …
super boulot