Salut tout le monde,
Y a quelques jours j’ai fait une analyse du code source de core YunoHost (et donc pas de tout YunoHost, juste le logiciel qui en est les fondations) grâce à git-of-thesus et @Aleks a fait pareil avec l’évolution de la qualité des applications. J’ai publié tout ça sur Mastodon parce que swag les médias sociaux libres. Suite à une suggestion je vous reproduis tout ça ici 
Ça faisait un moment que j’avais envie de faire de l’analyse de donnée sur l’activité de #YunoHost, rien que pour essayer de montrer l’activité qu’il y a parce que c’est : vraiment énorme et super varié.
Spoiler: j’y suis pas encore arrivé.
Par contre j’ai trouvé cet outil https://github.com/erikbern/git-of-theseus qui analyse un dépôt git et produit des jolies graphiques.
J’ai fait ça sur le core de #YunoHost (la partie où je taff le plus avec l’orga) et je vais vous faire un thread dessus
Avant de commencer, quelques précisions. git-of-theseus produit plusieurs types de graphiques :
- volume de code par année
- volume de code par auteur
- les deux normalisables
- et le % de commit toujours présent à travers le temps
Ca c’est les graphes d’exemples que git-of-theseus donne:
J’ai analysé les 4 dépots qui constituent le (“nouveau”) core de #YunoHost:
- la moulinette, notre framework (comme django/RoR) interne qui fait tout tourner (très peu connu)
- “yunohost core”, là où est toute la logique métier
- yunohost-admin, l’interface web d’administration qui parle au core
- ssowat, le sso plus connu sous “le portal de login des utilisateurs”
ATTENTION: c’est la deuxième version de #YunoHost, y en a eu une première en ruby que j’ai pas connu.
Donc je vais commencer par le “core” car c’est là qu’on voit le mieux ce qu’est #YunoHost aujourd’hui : un projet dont les fondations (les composants clefs) ont été codé par Kload et Jérôme (une personne très discrète mais prolifique) qui ont arrêté de contribuer début et fin 2016.
Et fin 2016 (après ma conf “1 an et demi de brique internet”) YunoHost se forme en collectif et où Aleks, ljf et moi prenons le relais sur les fondations.
Précision importante : je montre vraiment que le travail sur le core, y a ouatemille boulot tout autour, sur les apps, sur l’infra, sur le support, sur le forum, sur les confs etc…
Donc premier graphique à mettre en lien avec mon toot précédent où on voit vraiment les épisodes dans le core et comment il a fallu le collectif pour qu’on arrive à bosser et au début c’était plein de petits modifs peu visibles avant d’y avoir des + gros morceaux.
Autre graphique intéressant, celui du code par année.
On voit vraiment qu’on marche quasi que par addition de nouveau code (et légère corrections/nettoyage) car la moulinette permet d’avoir du code super orthogonale et que le code du début est toujours pertinent et utile (ou on veut pas y toucher aussi parfois >_>)
En version normalisée on voit qu’on a quand même doublé la masse de code depuis le collectif.
Dernier graphique moins intéressant mais qui m’amuse : le % de type fichiers par extensions dans le code : on voit qu’on est massivement codé en python (et les autres parties du code) mais surtout que super récemment on s’est mis à intégrer plein de helper en bash pour aider les mainteneurs d’applications à plus facilement et mieux faire leur taff (c’est une continuité du travail de Jérôme)
Maintenant pour les trucs moins glorieux 
… l’admin.
Ici les parties amusantes c’est comme on voit à quel point les pratiques de développement ont changé : on passe de “je fous les assets statiques dans le git” à “j’utilise le tooling npm/bower pour virer tout ça”
Plus intéressant sur l’admin, quand on normalise (sinon on voit rien :/)
- on voit que c’est kload qui a tout codé
- hugo ici a un % énorme, car il a rajouté bootstrap dans le git (mais son taff est mineur)
- on voit l’arrivé de opi qui va prendre l’admin en main et ± la refaire ? (pas sûr)
- puis après, à part Jérôme qui aura besoin de rajouter un gros truc et des petites contribs … aujourd’hui y a quasi plus personne qui bosse dessus
Le SSOwat maintenant, ou portal de login maintenant.
Pour la précision : c’est du code en lua/nginx, un truc ultra rare que quasi personne maîtrise, même si c’est “facile” à modifier, mais c’est surtout ultra pénible de bosser dessus …
Le graphique parle de lui-même : c’est quasi un taff exclusif de kload qui l’a fait “en une semaine” (dans mes souvenirs) puis de opi qui est venu le rendre joli.
Depuis c’est quasi mort :x
(on arrive même pas à merger les PRs externe dessus 
)
Et pour finir, la moulinette, le framework magique (un peu trop magique) qui fait tourner tout ça.
À nouveau, les graph montrent vraiment bien ce qui se passe:
- kload code toute la moulinette, avec un peu d’aide de beudbeud (l’autre fondateur avec kload)
- Jérôme arrive à recode TOUT
- depuis y a ± que Jérôme qui comprend(nait) comment elle marche
- par la suite, Aleks et moi on fera juste que des ajouts mineurs et quelques petites modifs/bugfixs
Pour écrire une mini conclusion:
- on voit vraiment le changement de cap et l’impact de la perte des gens qui font beaucoup de code
- ça se voit moins, mais on fait énormément de nettoyage et de bugfix, le projet est méga plus stable, mais on a très peu de nouvelles features
- je pense que c’est très lié à l’impact à la fois de la structure collective (se mettre d’accord sur une nouvelle feature : super dure, donc bugfix/amélioration sont bien plus tentant·e·s)
- on est pas bcp
Conclusion, suite:
- (mais on est beaucoup au total, beaucoup de monde sur les apps/support/forum)
- d’une certaine manière y a peut être plus si tant que ça besoin de nouveau code massif, à part certaines features, #YunoHost se suffit déjà assez bien en fait ?
- c’est dur de reprendre une vision en mode “tireur seul/à deux” quand c’est pas “notre projet” et qu’en plus on doit se mettre d’accord ben on voit l’impact
- we need help join us
Ah et je veux quand même réinsister : ça représente vraiment QUE le travail sur core, genre la plomberie, y a tellement de personnes autours que j’ai pas cité qui ont bossé sur plein plein plein d’autres aspects tout aussi important.
Juste, j’ai pas encore les outils pour montrer/analyser/voir leur taff là tout de suite (quand bien même ça soit possible)
Oh et un truc qui me revient : Kload avait une capacité assez fascinante pour pondre des briques clef en mode Yolo et les utiliser direct, ça a permit la chose clef d’avancer très vite partout (il a fait ça pour d’autres trucs comme la dynette pour le dyndns et simone le wiki)
Il avait aucune considération pour la qualité du code et la stabilité (enfin si, mais pas en mode perfectionniste) par contre
Opi aimait bien dire “il code un proto un jour et le met en prod le lendemain”
Et le graphique qui manque mais je sais pas s’il est très intéressant :
2 jours plus tard… https://social.wxcafe.net/@bram/100089885629843129
Suite à une demande @Aleks (oui, le aleks sur les slides) je vous fais 2 dépôts en plus :
- simone, l’outil yolodev (par kload #surprise) pour gérer la doc
- et la doc en elle-même stocké dans git donc partiellement analysable
Donc je vais commencer par Simone : c’est un wiki full static avec un frontend full js qui permet de faire des contributions depuis l’UI web qui sont pushés dans le git.
En pratique c’est ignoble avec un script php qui appelle un script ruby qui appelle un script bash et des histoires de javascript qui chargent du markdown convertie en html avec du js dedans rechargé comme du js aussi.
Kload ™
Et sans surprise : c’est kload qui a tout codé.
Opi-je-fais-le-ménage-de-l’html vient faire un tour juste après et puis … ça meurt comme plein de trucs que kload a fait et que plus personne veut toucher (j’ai un proto qui tourne dans un coin pour le refaire en django) (et y a plusieurs protos en générateurs de sites statiques qui trainent).
Hormis l’aspect ignoble ça reste pratique et ça nous sert toujours aujourd’hui #win
Plus intéressant : la documentation en elle-même. Y a plusieurs points qui apparaissent :
- y a plein de contribs (de l’épique mais pas que) qui sont agglutinées et pas nommée, on sait pas trop qui a fait quoi
- moul est le contrib principale et a fait une grosse différence à autant taffer sur la doc, ça compte vraiment
- depuis qu’il en fait moins, à part des points spécifiques y a plus personne pour jardiner
- énormément de petites contributions, ça fait une grosse différence
Et là c’est le thread de @Aleks https://cybre.space/@aleks/100096729584235479
Pour continuer dans la même veine des #YunoAnalyse de @bram je vous propose un thread pour mettre un peu en avant le travail de fourmis de l’équipe de packageurs d’apps de #YunoHost !
J’ai récemment produit les graphes que je voulais produire depuis super longtemps !
Je vais les poster, mais vous pouvez les trouver directement sur https://dash.yunohost.org/applist_history
Le premier graphe, c’est le nombre d’apps au fur du temps et en fonction de l’état déclaré par le mainteneur de l’app.
Depuis un an et demi, on est passé d’un catalogue de ~150 apps, dont 20 officielles et 64 déclarées “working” à maintenant ~230 apps, dont 23 officielles et 104(!) déclarées “working”.
Mais en tant que packageur, la partie installation d’une app sans soucis est souvent la partie visible de l’iceberg pour l’utilisateur final.
Derrière tout ça, il faut aussi gérer le backup/restore, l’intégration avec le SSO, les upgrades/migrations, les
compatibilités ARM et Stretch, etc… !
Ce n’est ni évident à développer ni à tester.
Pour cela, un système de niveau de qualité a été défini vers le début 2017 avec un système de test automatique (CI) pour tester automatiquement les choses.
Et c’est donc le deuxième graphe : pour toutes les apps officielles et community déclarées “working”, plein de tests automatiques sont faits, et un
niveau de 0 à 7 est attribué. Le graphe montre l’évolution des niveaux au cours du temps
À la mise en place au printemps 2017, nous n’avions que ~10 apps level 7. Depuis nous sommes passés à 50(!) apps level 7. En plus de cela, les résultats “mauvais” tendent à rester constant voir à diminuer !
Et note pour la fin : parmis les apps level 3, en fait nombre d’entres elles seraient très proches d’être level 7. Il s’agit souvent d’apps où l’intégration avec le SSO est compliquée non possible, ou bien qui ne respectent pas complètement certaines bonnes pratiques pour assurer la robustesse de l’app. Mais en gros fonctionnent plutôt bien quand même !
TL;DR : le taf des packageurs est énorme et super impressionnant 
:purple_sparkling_heart:
Voilà, félicitation si vous êtes arrivez jusque là 
J’espère que ça vous aidera à vous donner une idée, même si lointaine et incomplète (y a tellement plus autour) de tout le boulot qu’il y a derrière YunoHost (ou au moins son core et les apps)
Et qu’on a toujours tout autant besoin d’aide, join us \o/ https://yunohost.org/#/contribute_fr
