On devrait ajouter l’architecture dans le manifeste.
C’est une des YEP, mais je ne l’ai effectivement pas ajoutée. Peut-être que certaines YEP pourraient être ajoutées aux niveaux, ou même que chaque YEP ai un niveau associé.
C’est raide de refuser d’office les apps sans support ARM je trouve. Bien que je comprenne tout à fait ton argument.
Ce qui me dérange surtout, c’est que le support ARM est indépendant du packageur.
C’est un point délicat, je pense que nous devrions dans un premier temps faire un état des lieux des apps concernées avant de trancher cette question.
C’est un peu similaire pour le support SSO, ldap ou installation en path en fait car toutes les apps ne l’acceptent pas…
Mais en manifeste ça semble pas mal car on pourrait carrément ne pas les afficher sur la gui des arm et l’afficher clairement ailleurs (tout en prenant en compte dans les scripts toujours)
Mais OK pour reporter ça. Par contre si on reporte on n’autorise pas sans support arm entre temps ? Car sinon dir de revenir en arrière …
J’aime bien l’idée, ça me semble la meilleure solution. A discuter toutefois avec le groupe core dev.
C’est qu’à l’heure actuelle, nous n’avons pas de moyen de le savoir…
Je travaille à la possibilité d’attacher d’autres serveurs au serveur principal de CI. Dont évidemment une machine sous ARM.
Mais c’est en cours, d’une part, et je ne souhaite pas louer plusieurs serveurs sur mes propres fond d’autres part.
Je sais pas à quel point c’est envisageable mais ce serait pas mal si on pouvait caller une petite brique internet en collocation quelque part et s’en servir pour le CI ARM (“briqueproof” en même temps 
). A discuter sur un autre fil ou sur le chat …
Ah oui ce serait bien ça, c’est beaucoup plus intéressant de tester sur une brique que sur un VPS. On serait plus près de la réalité.
Nombre de logiciels ne tourneront pas (suffisamment) bien sur une brique. Donc bloquer le passage en officiel d’un logiciel qui ne tournerait pas sur une machine ARM, je ne trouve ça gênant.
Je reprends l’exemple de Jitsi, probablement que même une RPi 3 ne suffirait pas.
edit: corrigé 
C’est pas l’inverse que tu voulais dire?
C’est difficile de savoir à l’avance, et encore plus avec des tests automatisés, si une app tournera correctement sur une brique.
Suites aux dernière modifications, à savoir les niveaux pour valider les apps. Nous avons un avis positif de scith.
Pour clore cette décision et avancer sur cette question, il nous manque 2 avis du groupe d’ici à demain.
Bon, ça se bouscule pas 
Donc on va prolonger cette décision d’une semaine, soit le 13 janvier prochain.
Et sauf désaccord, je passe cette décision par un vote.
- D’accord pour classer les apps par niveaux et valider ainsi les apps officielles si elles atteignent le niveau 6.
- D’accord dans le principe, mais il y a des points à modifier.
- Pas d’accord avec cette idée.
0 voters
Concernant l’ajout de YEP à ces niveaux, il y a une proposition ici sur ce point.
Pour rappel, nous avons besoin de 5 avis positifs du membre du groupe Apps pour valider cette décision.
Je suis d’accord pour que le groupe app considère d’intégrer une app à la liste des apps officielles si elle est au niveau 6.
Selon moi, c’est une condition nécessaire mais pas suffisante.
Je pense qu’une validation par les membres du groupe app en tant que décision mineure ou moyenne serait bien.
Une relecture du code serait pas mal.
On est d’accord, comme je le disais un peu plus haut, le niveau 6 est un prérequis, mais le passage en officiel sera toujours le résultat d’une discussion (ou vote) du groupe avec une lecture attentive du code.
Je considère que les apps officielles sont une vitrine importante de YunoHost, donc on peut pas valider des apps sans vérifier.
J’ai un peut-être un peu trop résumé pour le vote.
C’est tellement évident qu’on l’a pas mit mais faut que l’application package un logiciel libre.
J’ai pas le temps de vraiment à fond re-réfléchir sur cette liste pour voir ce qu’il y aurait en + à rajouter. Je pense que ce qui manque apparaîtra naturellement à l’usage et là c’est déjà suffisamment bien.
Je crois avoir vu ça quelque part dans la doc, mais c’est vrai que là on l’a pas précisé. Mais quelque part, oui c’est tellement évident!
Je ne suis peut-être pas “habilité” à contribuer au vote (pas dans un groupe, seulement utilisateur très intéressé) mais en effet, malgré mon vote en faveur du classement par niveau et de la qualification d’officiel lorsque le niveau 6 est atteint, il faut insister sur la nécessité d’une relecture minutieuse du code (la base pour la confiance) !
Merci pour cette discussion éclairée, j’ai eu plaisir à la lire (à défaut de parvenir à dormir !) et celle-ci illustre bien les forces vives de ce fabuleux projet qu’est YunoHost.
A+
jellium, même si tu n’es pas dans un groupe, ton avis nous intéresse. Les discussion et les votes sont ouverts à tous, tout les avis sont les bienvenus.
Certes, ce sont les membres du groupes Apps qui prendront la décision finale, c’est le mode de décision qui a été retenu, mais tous les avis sont pris en considération.
YunoHost n’est pas utilisé seulement par une élite dans une tour d’ivoire, YunoHost appartient à tout ses utilisateurs.
Si tu veux plus d’informations sur le mode de fonctionnement et de prise de décisions de YunoHost, je t’invite à lire le document d’organisation 
1 Like
Cette décision est donc validée à l’unanimité 
A présent les applications seront notées par niveaux, représentant la qualité du package au regard des règles de packaging.
Et une application atteignant le niveau 6 pourra prétendre à devenir officielle en en faisant la demande. Et après discussion du groupe Apps.
Je prépare (ou du moins je vais le faire) une annonce générale pour annoncer ces nouvelles mesures qui viennent simplifier le packaging des applications.
Toutefois, avant de pouvoir faire une annonce, il y a plusieurs pull request à valider.
https://dev.yunohost.org/issues/711
https://github.com/YunoHost/apps/pull/120
ET toutes les PR des YEP https://github.com/YunoHost/doc/pulls
1 Like
Voici une suggestion pour inclure ça dans package_check @Maniack_Crudelis :
-
On intègre toutes les étapes à vérifier manuellement dans le check_process. Par exemple
user_management=1(l’app prend en charge les utilisateurs via LDAP et http auth le cas échéant),recommended_yep=1(l’app respecte toutes les YEP recommandées),all_yep=1(l’app respecte toutes les YEP optionnelles),perfect=1(l’app est parfaite). Ces éléments peuvent faire l’objet de PR après validation manuelle. Par défaut, ils sont à 0. (On peut même faire YEP par YEP mais ca semble fastidieux et surtout on a pas encore toutes les YEP) -
package_check est désormais en mesure d’établir et d’afficher le niveau maximum obtenu par l’app, les niveaux manquants et même si l’app possède au moins le niveau 6.
Effectivement, c’est une bonne idée, ça pourrait fonctionner. Toutefois, c’est les YEP après qui peuvent coincer. On a pas de moyen de les vérifier automatiquement.
Je pensais sinon à simplement rétrograder les apps avec package check si elles ne réussissent pas les tests correspondant. Mais c’est tout de suite moins automatisé.
Et garder la montée de niveau en manuel.
Ça fait plus de boulot, mais package check n’est pas infaillible tout de même.
Hm sinon on pourrait juste mettre les niveaux dans check_process avec possibilité “d’overrider” le calcul de package_check pour certains cas particuliers.
level1=auto; level2=auto; level3=1;
etc…
Les niveaux manuels ne peuvent pas être en auto (défaut à 0), on les met manuellement à 1 après analyse.
Les niveaux en auto sont calculés par package_check à chaque lancement (ou overridés avec 1 ou 0)
Comme ça en sortie de package_check on a le niveau final, qui peut être amélioré et rétrogradé (avec les niveaux en auto) ou plus ou moins forcé (en forçant certains niveaux à 1)
Je sais pas (a) si je suis clair et (b) si ça peut alléger le boulot de révision à terme en le concentrant dans le fichier check_process et le CI