LTS 18 ACTIVITY 2025

Vous trouverez sur cette page le compte rendu de l'activité "maintenance dolibarr 18 LTS pour 2025" ...

Rappel / Contexte

Le lancement de la branche LTS durant le devcamp de Lyon 2023 était conditionnée au fait d'avoir un ou deux responsables de cette branche du dépôt git qui s’engageaient sur la durée de la maintenance prévue. Comme tout nouveau rôle il faut apprendre à devenir "mergeur" et cette phase d'apprentissage est loin d'être triviale. Il ne suffit pas d'être développeur / contributeur pour être un "bon mergeur", il faut savoir changer de costume car le mergeur est responsable de la stabilité de l'ensemble du projet. Il doit donc savoir prendre du recul par rapport à une contribution pour l'évaluer dans son ensemble.

Organisation

L'organisation de l'équipe : 1h tous les jeudi matin "bloquée" (sanctuarisé) pour garder un rythme +1h de plus soit en débordant de la séance (souvent) soit pour creuser un aspect quand on a un client ou un use-case dans notre historique lié à une PR et qu'on va donc pouvoir mettre en perspective (situation réelle).

Comment :

• en visio sur le nextcloud mis à disposition par open-dsi : partage d'écran et analyse croisée des PR en audio
• liste des PR liées à la branche 18.0
• liste des PR review par le mergeur en appliquant le filtre : "is:pr base:18.0 is:closed reviewed-by:@me"

Remarques :

• domaine d'expertise: certaines PR sont sur des sujets hyper pointus, spécifiques et parfois très complexes et demandent une expertise métier que le mergeur n'a pas forcément
• problèmes récurrents pour lesquels des heures sont nécessaires: calculs d'arrondis / divisions par zéro / "le centimes d'écart"
• backports de versions "suivantes" (CVE) et parfois "pas possibles à l'identique"

A propos des PR

Ce qui pourrait être amélioré : la déclaration du bug que la PR corrige avec capture d'écran et comment reproduire le bug. Bien trop souvent la PR arrive avec un descriptif trop peu détaillé (exemple "FIX xxxx" sans beaucoup plus de détails) ... ce qui est un sous entendu évident pour le développeur qui fait sa PR ne l'est pas du tout pour le mergeur qui n'a aucune idée du contexte.

• il faudrait avoir un descriptif réel du bug ou un lien vers l'issue qui détaille le bug
• quelles étapes pour reproduire le bug
• des captures d'écran, un fichier sql, des pdf selon le bug corrigé

En résumé à part eldy les mergeurs ne sont pas dolimnicients (c'est une invention, omnicients sur dolibarr) et donc ça provoque des échanges, des délais et souvent des incompréhensions.

Pour le développeur c'est aussi une perte de temps car il envoie sa PR après avoir passé des heures à chercher et corriger son bug (imaginez que le mergeur va devoir faire le même chemin de recherche / analyse), quelques jours plus tard le mergeur va demander des détails, entre temps le développeur est passé à autre chose et le temps fait qu'il n'est plus dans le contexte.

De ce fait plus le développeur donne d'éléments détaillés dès le début et mieux c'est pour tout le monde:

• pour lui : il n'a pas à "revenir" sur son bug plusieurs jours plus tard pour trouver des éléments de détails
• pour nous il suffit de suivre le message pour bien comprendre le bug

Et en plus ça enrichi la "documentation" implicite du projet : si 2 ans plus tard vous revenez sur une PR vous aurez tous les détails / éléments de contexte pour comprendre pourquoi une correction a été faite et quelle option avait été prise.Exemple de PR complexes et du domaine lié:

• https://github.com/Dolibarr/dolibarr/pull/33859 -> compta
• https://github.com/Dolibarr/dolibarr/pull/36553 -> marges et arrondis

Bonne pratique pour vos prochaines PR

Exemple d'une PR "idéale" pour nous: elle est documentée et nous permet de comprendre rapidement le contexte et de reproduire la situation https://github.com/Dolibarr/dolibarr/pull/34511

D'autre part quelques automatismes ont été mis en place pour aider le travail des co-mergeurs :

• actions Github pour assigner automatiquement les reviewers sur les PR faites sur la version LTS de Dolibarr (v18)

Création de releases - Autre compétence "2025"

Après avoir passé l'année 2024 à monter doucement en compétence sur le rôle de mergeur nous nous sommes lancés dans la publication "release" d'une version dolibarr.

Passer de Mergeur à Release manager

La création d'une release demande du temps consécutif (et des ressources machine conséquentes), on ne peut pas commencer une publication de release stopper au bout d'une heure et reprendre la semaine suivante. C'est donc un problème d'organisation à anticiper du côté du Release Manager.

Cette année en devenant responsable de publication d'une release 18.0.7 puis 18.0.8 nous avons:

• fait une révision complète du script de création du paquet : https://github.com/Dolibarr/dolibarr/blob/develop/dev/build/makepack-howto.md

• documenté beaucoup de choses pour la production d'une release LTS : LTS DEV NOTES

En résumé en 2025: deux releases de dolibarr 18 ont été publiées par notre équipe release 18.0.7 (github) et release 18.0.8 (github) avec de grosses contributions à la documentation de "release manager" lié et des modification des scripts de release.

Encore une fois prendre le rôle de realse manager nous a donné l'occasion d'apprendre beaucoup de choses sur le projet Dolibarr, des choses qui sont bien souvent "invisibles" mais absolument nécessaires / indispensables au bon fonctionnement du projet (poser un tag après avoir généré le changelog, vérifier que les fichiers sont bien déployés sur les serveurs de l'association, gestion des différents formats de paquets etc.).

En guise de bilan rapide

Pour cette année 2025 nous pouvons vous communiquer les informations suivantes sachant que la majeure partie des choses ne sont pas quantifiables vu qu'elles sont du domaine de la compétence acquise par nos deux nouveaux mergeurs.

Au risque de vous faire sourire, il n'y a que depuis quelques mois que nous "osons" appuyer sur le bouton "merge" sans demander 20 fois à eldy si c'est bon :-) merci encore à toi pour ta patience et ta confiance, nous espérons nous en montrer digne.

Métrique

• Environ 100 PR fermées dont 90% validées, attention aux demandes qui ne sont pas du domaine du correctif de bug mais de 'nouvelle fonctionnalité' qu'il faut donc envoyer sur develop

• Il reste une quinzaine de PR en cours (ouvertes) et qui demandent de l'attention pour reproduire le bug à coup sur et évaluer les risques d'intégration dans le coeur

Axes d’évolution / amélioration

• Pour les PR
  • reprise automatisme d’assignation des « reviewers » (perte suite à modification Github)
  • mettre des labels : discussion, postponed, PR to merge, etc
  • procédure pour savoir si la PR est proposée est sur la bonne branche, il subsiste des difficultés d’interprétation du schéma dans certains cas (mais de moins en moins, c'est lié à la courbe de croissance des compétence des mergeurs) : Category:RoadMap
• création de releases
  • planification d'une publication d'une nouvelle release: à quel moment ? après fix CVE ? autre ?
  • comment savoir si la branche est figée pour préparer la prochaine « release » ? (pas visible pour les contributeurs et les co-mergeurs)
    • utilisation de labels sur les PR (par exemple "release en cours, votre PR sera étudiée juste après") ?
  • simplification du processus :
    • amélioration du script de création des paquets
    • « dockerisation » pour la création des paquets automatique et non lié à la configuration de la machine du release manager (reproductibilité) et tester la release
  • documentation plus détaillée
  • annonces à la communauté : canaux de diffusion

Bilan 2025 "perso" -> les mots des co-mergeurs

Point de vue de Lionel :

Ce fut une expérience très enrichissante et valorisante en tant que co-mergeur avec Eric Seigne (rycks) bien que les débuts ont été laborieux. Je ne savais pas jusqu’où irai cette aventure et si ça allait durer. Je pense que le travail en binôme a été primordial pour avancer et ne pas abandonner dans ce projet de création d’une première version LTS de Dolibarr. Le fait de pouvoir échanger et avoir un autre regard sur les correctifs proposés par les contributeurs Dolibarr est tellement formateur, que je me sens aujourd’hui plus à l’aise dans la relecture de code. La création et publication de « Releases » m’a été à la fois une étape risquée et tellement gratifiante que je me sens intellectuellement plus épanoui et grandi dans cette mission de co-mergeur. Je ne regrette pas cette aventure et je la poursuivrai avec joie. Je tiens à remercier mon binôme dans son soutien et sa volonté d’améliorer et pérenniser le code de Dolibarr. Je conseille vivement tout contributeur à venir partager cette expérience unique ...

Eric:

Lionel Vessiller est le co-mergeur parfait: régulier comme un métronome, toujours la au rendez-vous, pas une seule absence, fiabilité totale ... heureusement qu'il est là car tout seul je pense que j'aurais eu du mal à tenir dans la durée. Faire le boulot à deux oblige à faire les choses plus proprement que lorsqu'on est tout seul (on accepte souvent une petite entorse aux règles quand on est tout seul, ou alors les règles s'appliquent aux autres mais pas à soi-même ...). D'autre part notre bagage technique étant différent (bien qu'ayant un fond commun) il nous a permis de trouver des réponses à beaucoup de situations complexes et c'est avec beaucoup de plaisir que je retrouve Lionel tous les jeudi (ou presque) pour contribuer à Dolibarr. Merci Lionel pour ta rigueur et tes remarques du genre "mais attends, cette variable elle débarque d'où ?" ou "mais c'est pas du tout ça" quand je m'enflamme en cherchant à reproduire le bug qu'une PR est sensée corriger. Il me tarde de pouvoir élargir le groupe des mergeur avec la prochaine "LTS" pour continuer à solidifier l'équipe de Dolibarr.

Sponsoring pour le temps passé ?

La maintenance d’une version LTS comme Dolibarr 18 est un engagement exigeant, tant en temps qu’en expertise. Chaque heure passée à analyser, tester, documenter et publier les correctifs ou les releases est une heure de moins pour nos activités professionnelles.

Aujourd’hui, nous faisons appel à vous — utilisateurs, entreprises, partenaires — pour soutenir financièrement cette initiative. Votre contribution, quelle que soit sa taille, permettra de :

Lien vers la plate-forme de financement

• Pérenniser la maintenance de la branche LTS 18, en garantissant la stabilité et la sécurité de votre environnement de travail et permettra de lancer la prochaine version LTS en prouvant que le modèle économique est viable pour des mainteneurs de version.
• Améliorer la réactivité des correctifs et des releases, en nous permettant de consacrer plus de temps à la revue des PR et à la résolution des bugs complexes.
• Former de nouveaux mergeurs et release managers, pour élargir l’équipe et assurer la continuité du projet sur le long terme.

Que vous soyez une TPE, une PME ou un grand groupe, votre soutien est crucial. Il peut prendre la forme d’un don ponctuel ou d’un sponsoring récurrent. Chaque euro compte et sera intégralement réinvesti dans le projet.

En participant au financement, vous ne soutenez pas seulement un logiciel : vous investissez dans un écosystème open source dynamique, transparent et collaboratif. Vous bénéficiez directement des retombées de ce travail, tout en contribuant à la vitalité d’un projet qui profite à toute la communauté.

Comment contribuer ?

• Via la plateforme hébergée par CAP-REL : https://projets.cap-rel.fr/campaign/a7ee1d8ed675934d3457fdf5583690b5

Rejoignez-nous dans cette aventure collective. Votre participation est importante !