LTS 18 ACTIVITY 2025

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

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 mettre en perspective.

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 https://github.com/Dolibarr/dolibarr/pulls?q=is%3Apr+is%3Aopen+base%3A18.0

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"

Ce qui pourrait être amélioré : la déclaration du bug avec capture d'écran et comment reproduire le bug, 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 (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

bilan 2025 "perso" -> le mot du mergeur

release -> mergeur mais plus release manager

c'est ce qui est le plus long et qui mange le plus de ressources sur le poste du développeur : lancer une nouvelle release demande plusieurs heures de suite

automatisation

tests fonctionnels pour reproduire le bug quasi impossible

X PR validées

X PR refusées

Notes

Deux releases: 18.0.7 et 18.0.8 avec de grosses contributions à la documentation de "release manager" lié et des modification des scripts de release

.../...