417
edits
LTS 18 ACTIVITY 2025: Difference between revisions
Jump to navigation
Jump to search
no edit summary
Eric.seigne (talk | contribs) (Mise en forme) |
Eric.seigne (talk | contribs) No edit summary |
||
| 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==== | |||
*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==== | |||
Point de vue de Lionel<span> </span>:<blockquote> | Point de vue de Lionel<span> </span>:<blockquote> | ||