Concernant le core et les plugins-dist, il arrive qu’on se demande si un correctif doit être reporté ou non.
Pour améliorer le processus de décision, je propose qu’on fasse comme suit :
Ticket
- Si on sait que c’est un bug 4.4, le ticket doit idéalement contenir le label « bug » et la milestone « 4.4 »
- Si on a un doute, on laisse cette attribution à la team @maintenance, en lui accordant un petit délai raisonnable
- Si c’est pas un bug, ou que la demande de report n’est pas jusitifiée, la team maintenance peut refuser ou requalifier le ticket en autre chose qu’un bug.
Branche et PR
- On peut créer une branche avec le numéro du ticket, dans un fork, ou dans le dépot. Ex
666-titre-du-ticket. ça peut se faire automatiquement depuis la GUI de gitlab. - De cette manière, Gitlab associera automatiquement les labels et milestones au moment de la PR.
- La PR est faite sur la branche de dev (master ou 5.x selon les cas…)
La suite
- N’importe qui peut faire la revue de code a priori, mais la PR doit (toujours idéalement, mais je pense que c’est prudent rester un peu strict là-dessus) être approuvée par au moins 2 membres de la team maintenance.
-Lae mainteneureuse qui fait le merge a, à ce moment, toutes les infos pour faire le report si la milestone a été correctement définie. Iel est de fait tout à fait fondée d’exiger le respect de ce processus (et d’aider ou de se faire aider à s’approcher de se processus)
C’est une base. Des avis ?
