Peut-être faudrait-il abandonner le système de versions et réfléchir à un système de rolling release. Cela réduirait drastiquement le nombre de branches.
Hello,
+1, c’est à mon avis l’un des gros problèmes actuels.
@hop je plussoie le commentaire d’Éric, vos commentaires sont intéressants mais on aimerait bien savoir qui vous êtes 
1 « J'aime »
Tout à fait 
Les stats ne vont pas dans le sens de cet hypothèse:
Dolibarr a un taux d’intégration de PR de 95% aujourd’hui. Espérer avoir plus de PR mergées, et donc avoir un taux de 98% par exemple est clairement utopique surtout quand on sait que le taux de merge est plutôt de 50% sur les autres projets de taille équivalente (exemple Odoo: 30%, mais 85% pour ERPNext, mesuré en 2022)
Ce qui bloque aujourd’hui l’intégration de plus de merge, c’est l’instabilité que chaque merge génère et la phase de stabilisation qui est nécessaire pour « digérer » une PR d’évolution. Ce temps et cette charge de travail pour stabiliser des évolutions intégrées est exponentielle avec le nombre de PR intégrés. Ainsi, si on release 2 fois moins souvent, le temps et les efforts pour « stabiliser » est multiplié par 4. Vu autrement, pour un résultat identique en terme d’évolution, la charge de travail est multiplié par 2. Ou encore, pour un résultat identique en terme d’évolution et une charge de travail identique, la qualité de stabilisation est divisé par 2 en releasant 2 fois moins souvent.
Aujourd’hui l’intégration de nouvelles PR est actuellement volontairement freiné pour pouvoir digérer les PR intégrés. En effet, le goulot d’étranglement est surtout au niveau du nombre de contributeurs qui « corrigent et stabilisent » les PR intégrés. Rappelons les chiffres, évalués lors d’un ancien devcamp : Sur Dolibarr, pour 1 PR d’évolution intégrée, il faut environ obtenir 2 PR de fix de stabilisation (évaluation 2022 faite sur Odoo: 2.5, sur erpnext: 7)
Hors aujourd’hui le nombre d’évolutions proposés et qui sont intégrés est plus important que le nombre de fix ou de stabilisations (normalisation, sécurisation, …) proposées alors qu’il devrait être de 1 PR sur 3 seulement pour être à l’équilibre.
Bref, il n’y a pas de sous effectif sur le merge (d’ailleurs la charge de travail quand on connait bien l’appli est assez faible) mais un sous effectif sur les Fixeurs, Débuguers et Killer de dettes techniques que j’appelerais avec les initiales, les FDK pour la suite (ceux qui bossent durant une phase beta pour remettre l’application stable et/ou cohérente, corriger les régression, mais aussi durant les phases de dev pour réduire la dette technique par exemple).
Un mergeur peut se remplacer car c’est une tache qui nécessite de la connaissance technique forte, historique et vision anticipative certes, mais peu de mobilisation (scoop: on va quand même essayer une expérimentation de former au metier de mergeur au prochain devcamp !).
Par contre, la où le projet est en risque, c’est le manque de FDK (car il repose sur quelques personnes uniquement et c’est une activité qui nécessite un gros investissement de travail). C’est là que se trouve le « bus factor », sur les FDK (je vous laisse aller voir su wikipedia la définition de Bus Factor). L’idée de releaser plus souvent (rappel: rendre stable une version est exponentiel à la quantité d’évolution de cette version) est la solution prise par beaucoup de projets pour rendre la stabilisation plus facile, jusqu’à pousser le système en « rolling release » mensuelle, ou hebdo par certains. Pour Dolibarr, un rythme mensuel ou même trimestriel est malheureusement trop rapide car il faut laisser le temps à la communauté d’analyser et commenter chaque PR, ce qui ne se fait pas dans un planning non contraint du fait du mode communautaire du projet.
Bref si vous avez des idées pour augmenter le nombre de « FDK », ou inciter des acteurs à se convertir de développeur métier vers FDK, c’est le bienvenu, car c’est la le goulot d’étranglement et là ou le projet est à risque (le problème est que développeur métier se vend aux clients, mais pas FDK). Si on trouve un « truc » pour motiver des acteurs pour assurer ce role en soutien de la poignée de FDK existant (les doigts de la main suffisent à les compter), on fera un gros progrès sur la stabilisation…
« Point de vue perso, car tiré d’expérience perso… »
2 « J'aime »
Merci pour les stats et ces explications, cela permet d’avoir une meilleure vision d’ensemble.
En ce qui concerne les FDK j’ai quelques suggestions à faire.
-
Essayer de parrainer ou d’épauler des développeurs nouveaux venus sur le projet Dolibarr, en les accompagnant pour leur première PR par exemple. Tout le mécanisme de github et le fonctionnement d’un projet open source peut être intimidant et freiner la participation des néophytes
-
Le plus long pour fixer un bug c’est souvent de mettre en place la configuration qui permet de le reproduire. On pourrait faciliter le travail des FDK en mettant à disposition des BDD de test pour les différentes versions de Dolibarr. Le FDK n’aurait alors qu’a faire le checkout de version sur laquelle on veut corriger le bug et de restaurer la BDD correspondante.
-
Ensuite améliorer les tags sur les issues github, en précisant les versions de Dolibarr et/ou de php concernées, peut être également préciser si cela concerne l’API et/ou quel module du core. Ou du moins au moins faire ressortir les issues qui nécessitent réelement un fix.
-
Fermer également les issues qui n’en sont pas comme Bug: · Issue #26114 · Dolibarr/dolibarr · GitHub (exemple extrême, mais il y a un certain nombre de sujets ouverts sans intérêt qu’on peut fermer pour nettoyer la liste)
Petite suggestion supplémentaire.
Certains projets open source organisent le mois précédent la sortie d’une nouvelle version une période de correction des bugs qui « trainent » en invitant le plus de monde possible à participer. Le but étant de fixer le plus de bugs possibles.
Bonjour,
Là où on pourrait grandement améliorer dolibarr, c’est sur les tests E2E, car une grande partie des tests doivent être faits manuellement. Faire des release régulière, et donc faire de l’utilisateur final le testeur, lui donne l’impression que la solution n’est pas stable.
J’ai découvert récemment Jdi-light qui permet de définir les éléments de la page dans un objet et ensuite dans les tests, il ne reste plus qu’à interagir avec les objets.
Dans les exemples, on peut voir la définition d’un formulaire puis la saisie du formulaire se fait simplement via un DTO (exemple).
L’écriture des tests est moins chronophage que du selenium classique.
C’est en java, mais ne demande pas un niveau de connaissance élevé de java.
De plus, la définition pourrait être un artefact java pour permettre aux développeurs de module de l’importer facilement et de faire des tests de leurs modules plus rapidement, car il aurait déjà toute la partie dolibarr défini.
En cas de changement dans l’UI, on modifie la définition de la page et si le comportement ne change pas, pas de changement du test nécessaire.
Personnellement, je pense qu’une LTS n’est pas nécessaire. En revanche, il faudrait réfléchir à une réelle mise en place de dépréciations sur au moins deux versions avec un warning qui indique sur quelle version ce comportement sera supprimé et pas juste un @deprecated sur une fonction et quand il y a un deprecated, mettre la version ou ça ne fonctionnera plus. Si on doit changer le comportement ou la signature d’une fonction, on en crée une nouvelle, on modifie l’ancienne pour qu’elle soit compatible avec l’ancienne.
Concernant les modifications de la base de données, on ne devrait pas changer d’une version à une autre, mais garder les deux dans le même principe des dépréciations et avoir un référentiel de changement d’une version à une autre (avec une colonne pour dire si c’est déprécié ou supprimé)
Comme le dit @hop, un ménage dans les issues GitHub ne ferait pas de mal.
Concernant les PR qui ont besoin d’être validés, on pourrait avoir des issues avec un tag du genre « PR to be tested » ainsi que sa version de sortie et la procédure de test, qui permettrait au non-développeurs de faire des retours. Derrière, le travail des développeurs est largement diminué.
Pour ça, il faudrait une instance de dolibarr mise à jour régulièrement, pour que les testeurs puissent facilement tester sans avoir de compétence particulière.
1 « J'aime »
Oh que oui ! mauvaise surprise cette semaine avec le 8ème (!) paramètre de la fonction ShowInputField qui est devenu obligatoire ! (pas dans la signature mais testé en début de fonction qui s’arrête si pas renseigné).
Pour la LTS dont le principe génère plein de débats depuis des années, mon avis n’est plus aussi tranché, vu que les nouvelles versions apportent de nouvelles fonctionnalités métiers souvent importantes (et si ce n’est pas le cas, ne pas faire une nouvelle version pour faire une nouvelle version mais sortir une 17.1.0 par exemple au lieu d’une v18).
Pour les tests, ce qu’il manque à mon sens, ce ne sont pas des tests développeurs, mais des tests métiers; on a souvent l’impression qu’une PR a été incorporée dans le core sans qu’une réflexion et des tests métiers aient eu lieu EN AMONT !
Nulle critique envers la personne qui merge et qui est abat un boulot énorme, mais critique plus globale de l’organisation du projet qui est à mon sens géré comme une distribution linux et pas comme un ERP où le fonctionnel et l’expérience utilisateur sont primordiaux (je suis conscient de ne pas forcément m’exprimer clairement, mais ça prendrait des heures de détailler).
On pourrait imaginer une étape de validation fonctionnelle des PRs par une équipe dédiée (et bénévole, j’ai bien conscience du problème) avant toute revue de code et éventuelle intégration.
On pourrait également imaginer des niveaux de contributeurs (plus sérieux que Joda et autres Jedis) qui fait que quand la PR provient d’une source « pro » (où la PR a été testée en interne, voire mise en prod chez des clients), elle soit priorisée par rapport à des PRs provenant de contributeurs moins aguerris ou organisés.
En même temps j’ai parfois l’impression que c’est le cas pour les PRs provenant de telle ou telle société, mais le niveau de tests en amont ou de qualité du code n’est pas toujours au rendez-vous; donc mon raisonnement tombe un peu.
Pour ça il y a la branche develop que les devs peuvent récupérer, mais comme dit plus haut, je pense que ce sont plutôt des tests fonctionnels qui manquent.
oui mais… qui a les droits pour le faire ???
Bon week-end à tous, je vais essayer de débrancher
Hello à tous !
Je rejoint @altatof sur les tests métier.
Je je suis pas du tout un développeur aguerris mais je sais debeugger, analyser une erreur.
Actuellement je suis gérant d’une imprimerie numérique / studio graphique.
On se sert bien évidement de Dolibarr tous les jours pour la gestion de notre société.
Je travaille beaucoup avec @erics, et surtout sur les modules qu’il développe.
Assez régulièrement je lui fait un état de outils que j’utilise et des erreurs que je peux rencontrer, en lui remontant comment j’ai produit l’erreur, comment la reproduire, et tous les logs nécessaires pour essayer de corriger.
Je pense que « mon profil » d’utilisateur est assez important. Des utilisateurs qui se servent en prod de Dolibarr et qui peuvent rencontrer des soucis « spécifiques » tous les jours.
Ça permet de corriger des « bugs » chaque jour et donc peut-être partir sur une LTS.
J’ai tendance à faire les MAJs dès que la vXX.0.1 sort, histoire d’être à jour, de découvrir les nouvelles fonctionnalités, mais souvent je n’en ai pas besoin, c’est mon côté « geek » qui m’appelle !
Alors quand il y a des bugs, on se débrouille à corriger comme on peut, mais c’est vrai qu’une LTS pour tous les jours, et des instances de tests pour assouvir mon côté geek irai très bien !
Voilà 
2 « J'aime »
Hello,
Tous les AMirals à mon avis : Sign in to GitHub · GitHub
J’y passe de temps en temps, pour essayer de faire le tri, mais globalement, il y a une proportion énorme de Feature Request dans tous les « vieux ».
Eldy à activer le GITHub bot, qui les fermes automatiquement au bout d’un an, je pense.
page not found (pour les amiraux); il me semble que la dernière fois que j’ai regardé ça sur le wiki je crois, je n’avais pas de grade malgré mes années de contributions (j’ai commencé à utiliser Dolibarr en 2005…)
Oui, c’est vraiment étrange que @eldy ne t’ai toujours pas rajouté…
En tout cas il y a 61 personnes :
@altatof essai de demander ton inscription : Sign in to GitHub · GitHub
On peut aussi prendre le problème autrement, la demande d’une version LTS vient du fait que ça prend du temps de mettre à jour les modules.
J’ai créé cette PR pour ajouter Rector à dolibarr
En cas de changement de signature d’une fonction ou de renommage, on pourrait créer des règle de refactorisation qui pourrait grandement aider la mise à jour des modules.
Pour montrer rector en action, il y a également cet PR qui a changé les $conf->global vers getDolGlobalInt ou getDolGlobalString en fonction du type
1 « J'aime »
peut-etre commencé par le commencement, à savoir définir la durée de vie d’une LTS
Si je m’en tien à wikipédia, on parle généralement de 3 ans soit 6 version de Dolibarr « normale »
Il conviendrait sans doute de revoir la numérotation pour savoir de quoi l’on parle.
Actuellement nous avons 3 chiffres soit : 16.0.4
pourquoi ne pas réserver le premier chiffre au changement de LTS, le deuxième au version semestrielle et enfin les mises à jour correctives
- Les LTS serait toujours des 20.0.x
- Les semestrielles des 20.2.x
L’avantage des LTS ce serait aussi de pouvoir réaliser un travail de fond de restructuration des dossiers de dolibarr qui est un bordel infame.
On aurait donc :
- LTS restructuration des dossiers
- STS restructuration des tables
- correction de base
Si on part sur 3 ans pour une LTS, et sachant qu’actuellement on maintient de front 3 versions (N, N-1 et N-2), en ralentissant le rythme de sortie des versions à une par an et en continuant à maintenir de front 3 versions (donc la même charge de travail), chaque nouvelle version aurait une durée de vie de 3 ans.
Mais c’est juste mon avis personnel.
@hop il faut vraiment prendre le temps de lire les messages de @eldy … ralentir les numéros de version ne changera rien à la situation et je pense que eldy est vraiment bien placé pour parler de ça …
Sans compter que d’avoir une LTS permettra de fiabiliser les versions semestrielles avec moins de livraison structurelle que l’on est obligée de torcher en moins de six mois pour passer dans le cadre du STS
Cette histoire de deux versions majeure pénalise VRAIMENT les évolutions en profondeur du core, il est temps d’évoluer
1 « J'aime »
Bonjour,
Personnellement, je ne suis pas pour ce schéma de versionnage.
La convention est que le premier chiffre change quand des modifications non rétrocompatibles sont effectuées. Le deuxième chiffre ajoute/modifie des fonctionnalités visibles pour l’utilisateur sans pour autant casser la rétro compatibilité. Enfin le dernier chiffre est pour les patchs (corrections de bugs uniquement) et sans impact de rétrocompatibilité non plus.
Après, si pas de breaking change pendant la durée de la LTS, ça me gêne pas mais sinon ça va à l’encontre du SemVer.
1 « J'aime »
