417
edits
LTS 18 ACTIVITY 2025: Difference between revisions
Jump to navigation
Jump to search
no edit summary
Lvessiller (talk | contribs) No edit summary |
Eric.seigne (talk | contribs) No edit summary |
||
| Line 39: | Line 39: | ||
*<nowiki>https://github.com/Dolibarr/dolibarr/pull/36553</nowiki> -> marges et arrondis | *<nowiki>https://github.com/Dolibarr/dolibarr/pull/36553</nowiki> -> marges et arrondis | ||
Quelques automatismes ont été mis en place pour aider le travail des co-mergeurs : | 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) | ||
===== 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> | ||
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 ...</blockquote> | 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 ...</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> | |||
Release -> mergeur mais plus release manager | ===== 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<span> </span>: lancer une nouvelle release demande plusieurs heures de suite | c'est ce qui est le plus long et qui mange le plus de ressources sur le poste du développeur<span> </span>: lancer une nouvelle release demande plusieurs heures de suite | ||
* automatisation | *automatisation | ||
* tests fonctionnels pour reproduire le bug quasi impossible | *tests fonctionnels pour reproduire le bug quasi impossible | ||
* révision du script de création du paquet pour la release : https://github.com/Dolibarr/dolibarr/blob/develop/dev/build/makepack-howto.md | *révision du script de création du paquet pour la release<span> </span>: https://github.com/Dolibarr/dolibarr/blob/develop/dev/build/makepack-howto.md | ||
* documentation réalisée pour la production d'une release LTS : [[LTS DEV NOTES]] | *documentation réalisée pour la production d'une release LTS<span> </span>: [[LTS DEV 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 | 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 | ||
===== Métrique ===== | |||
*Environ 100 PR fermées dont 90% validées | |||
* Environ 100 PR fermées dont 90% validées | |||
*Il reste une quinzaine de PR en cours (ouvertes) | |||
Axes d’évolution / amélioration | ==== Axes d’évolution / amélioration ==== | ||
* pull requests | *pull requests | ||
** reprise automatisme d’assignation des « reviewers » (perte suite à modification Github) | **reprise automatisme d’assignation des « reviewers » (perte suite à modification Github) | ||
** mettre des labels : 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 : | **procédure pour savoir si la PR est proposée est sur la bonne branche<span> </span>: | ||
*** difficultés d’interprétation du schéma : [[:Category:RoadMap|Category:RoadMap]] | ***difficultés d’interprétation du schéma<span> </span>: [[:Category:RoadMap|Category:RoadMap]] | ||
* création de releases | *création de releases | ||
** planification : à quel moment ? après fix CVE ? autre ? | **planification<span> </span>: à 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) | **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 ? | ***utilisation de labels sur les PR ? | ||
** simplification du processus : | **simplification du processus<span> </span>: | ||
*** amélioration du script de création des paquets | ***amélioration du script de création des paquets | ||
*** « dockerisation » pour la création des paquets et tester la release | ***« dockerisation » pour la création des paquets et tester la release | ||
** documentation plus détaillée | **documentation plus détaillée | ||
** annonces à la communauté : canaux de diffusion | **annonces à la communauté<span> </span>: canaux de diffusion | ||
<br />.../... | <br />.../... | ||