LTS 18 ACTIVITY 2025 - Revision history

Eric.seigne at 08:23, 12 February 2026

2026-02-12T08:23:45Z

← Older revision		Revision as of 08:23, 12 February 2026
Line 108:		Line 108:
	Aujourd’hui, nous faisons appel à vous — utilisateurs, entreprises, partenaires — pour soutenir financièrement cette initiative. Votre contribution, quelle que soit sa taille, permettra de<span> </span>:		Aujourd’hui, nous faisons appel à vous — utilisateurs, entreprises, partenaires — pour soutenir financièrement cette initiative. Votre contribution, quelle que soit sa taille, permettra de<span> </span>:

	[[File:LTS Staff.png\|alt=Lien vers la plate-forme de financement\|thumb\|Lien vers la plate-forme de financement]]		[[File:LTS Staff.png\|alt=Lien vers la plate-forme de financement\|thumb\|[https://projets.cap-rel.fr/campaign/a7ee1d8ed675934d3457fdf5583690b5 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.		*'''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.

Eric.seigne at 08:23, 12 February 2026

2026-02-12T08:23:04Z

← Older revision		Revision as of 08:23, 12 February 2026
Line 107:		Line 107:

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

			[[File:LTS Staff.png\|alt=Lien vers la plate-forme de financement\|thumb\|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.		*'''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.
Line 116:		Line 118:
	En participant au financement, vous ne soutenez pas seulement un logiciel<span> </span>: 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é.		En participant au financement, vous ne soutenez pas seulement un logiciel<span> </span>: 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é.

	~~[[File:LTS Staff.png\|alt=Lien vers la plate-forme de financement\|thumb\|Lien vers la plate-forme de financement]]~~

	'''Comment contribuer ?'''		'''Comment contribuer ?'''

Eric.seigne at 08:22, 12 February 2026

2026-02-12T08:22:28Z

← Older revision		Revision as of 08:22, 12 February 2026
Line 99:		Line 99:
	Eric:<blockquote>		Eric:<blockquote>
	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.</blockquote>		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.</blockquote>
	~~[[File:LTS Staff.png\|alt=Lien vers la plate-forme de financement\|thumb\|Lien vers la plate-forme de financement]]~~


Line 116:		Line 115:

	En participant au financement, vous ne soutenez pas seulement un logiciel<span> </span>: 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é.		En participant au financement, vous ne soutenez pas seulement un logiciel<span> </span>: 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é.

			[[File:LTS Staff.png\|alt=Lien vers la plate-forme de financement\|thumb\|Lien vers la plate-forme de financement]]

	'''Comment contribuer ?'''		'''Comment contribuer ?'''

Eric.seigne at 08:22, 12 February 2026

2026-02-12T08:22:01Z

Eric.seigne: sponsoring

2026-02-12T08:19:40Z

sponsoring

← Older revision		Revision as of 08:19, 12 February 2026
Line 101:		Line 101:


	Sponsoring pour le temps passé ?
			'''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 :

			* '''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 !'''

Eric.seigne at 08:29, 5 February 2026

2026-02-05T08:29:56Z

← Older revision		Revision as of 08:29, 5 February 2026
Line 29:		Line 29:

	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.		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:'''		'''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:'''

Eric.seigne at 08:29, 5 February 2026

2026-02-05T08:29:44Z

← Older revision		Revision as of 08:29, 5 February 2026
Line 36:		Line 36:
	*pour nous il suffit de suivre le message pour bien comprendre le bug		*pour nous il suffit de suivre le message pour bien comprendre le bug

	Et en plus ça enrichi la "documentation" implicite du projet<span> </span>: 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.		Et en plus ça enrichi la "documentation" implicite du projet<span> </span>: 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é:


	Exemple de PR complexes et du domaine lié:

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

	==== Bonne pratique pour vos prochaines PR ====		====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		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<span> </span>:		D'autre part quelques automatismes ont été mis en place pour aider le travail des co-mergeurs<span> </span>:

Eric.seigne at 08:27, 5 February 2026

2026-02-05T08:27:16Z

← Older revision		Revision as of 08:27, 5 February 2026
Line 43:		Line 43:
	*https://github.com/Dolibarr/dolibarr/pull/33859 -> compta		*https://github.com/Dolibarr/dolibarr/pull/33859 -> compta
	*https://github.com/Dolibarr/dolibarr/pull/36553 -> marges et arrondis		*https://github.com/Dolibarr/dolibarr/pull/36553 -> marges et arrondis

			==== Bonne pratique pour vos prochaines PR ====

Eric.seigne at 08:22, 5 February 2026

2026-02-05T08:22:23Z

← Older revision		Revision as of 08:22, 5 February 2026
Line 44:		Line 44:
	*https://github.com/Dolibarr/dolibarr/pull/36553 -> marges et arrondis		*https://github.com/Dolibarr/dolibarr/pull/36553 -> marges et arrondis

	~~Quelques~~ automatismes ont été mis en place pour aider le travail des co-mergeurs<span> </span>:
			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<span> </span>:

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

Eric.seigne at 07:42, 5 February 2026

2026-02-05T07:42:12Z

← Older revision		Revision as of 07:42, 5 February 2026
Line 1:		Line 1:
	Vous trouverez sur cette page le compte rendu de l'activité "maintenance dolibarr 18 LTS pour 2025" ...		Vous trouverez sur cette page le compte rendu de l'activité "maintenance dolibarr 18 LTS pour 2025" ...

	=== Rappel / Contexte ===		===Rappel / Contexte===
	Le lancement de la branche LTS durant le [[DevCamp Lyon 2023 hiver\|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.		Le lancement de la branche LTS durant le [[DevCamp Lyon 2023 hiver\|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 ===		===Organisation===
	L'organisation de l'équipe<span> </span>: 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).		L'organisation de l'équipe<span> </span>: 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).

Line 19:		Line 19:
	*backports de versions "suivantes" (CVE) et parfois "pas possibles à l'identique"		*backports de versions "suivantes" (CVE) et parfois "pas possibles à l'identique"

	=== A propos des PR ===		===A propos des PR===
	Ce qui pourrait être amélioré<span> </span>: 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.		Ce qui pourrait être amélioré<span> </span>: 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.

Line 48:		Line 48:
	*actions Github pour assigner automatiquement les reviewers sur les PR faites sur la version LTS de Dolibarr (v18)		*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" ===		===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.		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.

Line 64:		Line 64:
	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.).		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 ===		===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.		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.		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<span> </span>:-) merci encore à toi pour ta patience et ta confiance, nous espérons nous en montrer digne.

	=====Métrique=====		====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		*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
Line 80:		Line 80:
	**reprise automatisme d’assignation des « reviewers » (perte suite à modification Github)		**reprise automatisme d’assignation des « reviewers » (perte suite à modification Github)
	**mettre des labels<span> </span>: discussion, postponed, PR to merge, etc		**mettre des labels<span> </span>: 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<span> dans certains cas (mais de moins en moins, c'est lié à la courbe de croissance des compétence des mergeurs)</span> : [[:Category:RoadMap\|Category:RoadMap]]		**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<span> dans certains cas (mais de moins en moins, c'est lié à la courbe de croissance des compétence des mergeurs)</span><span> </span>: [[:Category:RoadMap\|Category:RoadMap]]
	*création de releases		*création de releases
	**planification<span> d'une publication d'une nouvelle release</span>: à quel moment ? après fix CVE ? autre ?		**planification<span> d'une publication d'une nouvelle release</span>: à quel moment ? après fix CVE ? autre ?
Line 92:		Line 92:

	<br />		<br />
	=====Bilan 2025 "perso" -> les mots des co-mergeurs=====		====Bilan 2025 "perso" -> les mots des co-mergeurs====

	Point de vue de Lionel<span> </span>:<blockquote>		Point de vue de Lionel<span> </span>:<blockquote>