60
edits
LTS 18 ACTIVITY 2025: Difference between revisions
Jump to navigation
Jump to search
no edit summary
Lvessiller (talk | contribs) No edit summary |
Lvessiller (talk | contribs) No edit summary |
||
| Line 7: | Line 7: | ||
*en visio sur le nextcloud mis à disposition par open-dsi<span> </span>: 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> | ||
*liste des PR review par le mergeur en appliquant le filtre : "is:pr base:18.0 is:closed reviewed-by:@me" | *liste des PR review par le mergeur en appliquant le filtre<span> </span>: "is:pr base:18.0 is:closed reviewed-by:@me" | ||
Remarques<span> </span>: | Remarques<span> </span>: | ||
| Line 23: | Line 23: | ||
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 | ||
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. | ||
| Line 40: | 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 : | |||
* 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 | |||
Point de vue de Lionel<span> </span>:<blockquote> | Point de vue de Lionel<span> </span>:<blockquote> | ||
| Line 47: | Line 50: | ||
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 | |||
* documentation réalisée pour la production d'une release LTS : [[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 | |||
Métrique | |||
* Environ 100 PR fermées dont 90% validées | |||
* Il reste une quinzaine de PR en cours (ouvertes) | |||
| Line 65: | Line 75: | ||
Axes d’évolution / amélioration | |||
* pull requests | |||
** reprise automatisme d’assignation des « reviewers » (perte suite à modification Github) | |||
** mettre des labels : discussion, postponed, PR to merge, etc | |||
** procédure pour savoir si la PR est proposée est sur la bonne branche : | |||
*** difficultés d’interprétation du schéma : [[:Category:RoadMap|Category:RoadMap]] | |||
* création de releases | |||
** planification : à 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) | |||
*** utilisation de labels sur les PR ? | |||
** simplification du processus : | |||
*** amélioration du script de création des paquets | |||
*** « dockerisation » pour la création des paquets et tester la release | |||
** documentation plus détaillée | |||
** annonces à la communauté : canaux de diffusion | |||
<br />.../... | <br />.../... | ||