60
edits
LTS 18 ACTIVITY 2025: Difference between revisions
Jump to navigation
Jump to search
Bilan perso
Eric.seigne (talk | contribs) (brouillon) |
Lvessiller (talk | contribs) (Bilan perso) |
||
| 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" ... | ||
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. | 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 mettre en perspective. | ||
Comment : | Comment<span> </span>: | ||
* en visio sur le nextcloud mis à disposition par open-dsi : partage d'écran et analyse croisée des PR en audio. | *en visio sur le nextcloud mis à disposition par open-dsi<span> </span>: partage d'écran et analyse croisée des PR en audio. | ||
* liste des PR liées à la branche 18.0 <nowiki>https://github.com/Dolibarr/dolibarr/pulls?q=is%3Apr+is%3Aopen+base%3A18.0</nowiki> | *liste des PR liées à la branche 18.0 <nowiki>https://github.com/Dolibarr/dolibarr/pulls?q=is%3Apr+is%3Aopen+base%3A18.0</nowiki> | ||
Remarques : | Remarques<span> </span>: | ||
* 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 | *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" | *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" | *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. | Ce qui pourrait être amélioré<span> </span>: 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 | *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 | *quelles étapes pour reproduire le bug | ||
* des captures d'écran, un fichier sql, des pdf selon le bug corrigé | *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 | 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 | ||
| Line 28: | Line 28: | ||
'''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:''' | ||
* pour lui : il n'a pas à "revenir" sur son bug plusieurs jours plus tard pour trouver des éléments de détails | *pour lui<span> </span>: 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 | *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. | 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é: | ||
* <nowiki>https://github.com/Dolibarr/dolibarr/pull/33859</nowiki> -> compta | *<nowiki>https://github.com/Dolibarr/dolibarr/pull/33859</nowiki> -> compta | ||
* <nowiki>https://github.com/Dolibarr/dolibarr/pull/36553</nowiki> -> marges et arrondis | *<nowiki>https://github.com/Dolibarr/dolibarr/pull/36553</nowiki> -> marges et arrondis | ||
bilan 2025 "perso" -> le mot du mergeur | bilan 2025 "perso" -> le mot du mergeur | ||
Point de vue de Lionel :<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> | |||
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 : 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 | ||