Effectivement il faudrait prendre plus de temps sur la relecture. La difficulté est de le faire en un temps raisonnable par rapport au projet avec les ressources et compétences disponibles. On pourrait avoir une relecture en deux temps : une première pour fusionner sur la branche master
pour permettre d’avancer sur des fonctionnalités interdépendantes, et une deuxième sur stable
pour dire que le code est prêt à partir en production. Ça permettrait peut-être de combiner la nécessité d’avancer qui apparaît de temps en temps et les exigences en matière de qualité que l’on est en droit d’attendre de Duniter. Est-ce que tu penses qu’une branche stable
permettrait de prendre le temps nécessaire pour une bonne relecture ?
Ça peut être dev
et master
aussi.
Si je comprends bien, le processus serait :
- MR vers master
- relecture pouvant être rapide si une autre MR dépend de celle-ci
- merger dans master
- re-relecture pouvant donner lieu à une MR corrective dans master
- Pour ne pas oublier quelles MR doivent être re-relues, et pour ne pas re-relire celles qui l’ont déjà été suffisamment, il faudrait que chaque relecture rapide soit notée dans une todo-list, dans je-ne-sais quel outil de GitLab ou bien dans un fichier du dépôt (qui serait vérifié avant chaque rebasage dans stable).
- merger ou rebaser dans stable
Oui, dev
et master
conviennent aussi comme noms. C’est bien comme ça que j’imaginais cet éventuel nouveau processus. Pour savoir quelles MR ont été relues avec attention par un tiers n’ayant pas participé à l’écriture, on pourrait tout simplement avoir un tag #audited
ou #reviewed
dans la MR d’origine.
Si on avait les moyens financiers, on pourrait même déléguer cette tâche à un acteur tiers spécialisé dans l’audit de code.
Vu ce qui se passe en ce moment, je me dis que l’important n’est pas tant master
, stable
ou dev
, mais plutôt les branches de réseau, en particulier network/g1
. Effectivement, il faudrait que chaque commit intégré dans cette branche de réseau ait reçu plusieurs #audited
de telle sorte à ce que les forgerons à qui on demande d’installer une version de Duniter puissent vérifier que toutes les MR aient reçu une relecture.
Je recommande plutôt de ne garder que la branche master et une branche par release.
Plutôt qu’une autre branche, il est possible de coder un petit script qui génère un tableau avec toutes les MR mergés entre deux releases, et indique le nombre de review avec une coche verte ou une croix rouge.
Ca pourrait être un script qui s’exécute en première étape du processus de release et qui fait échouer le processus de release si toutes les MR n’ont pas un certain label par exemple. La personne qui fait la release reste libre d’ajouter manuellement le label manquant à chaque MR, mais ça oblige à opt-in manuellement et donc à ce demander; est-ce que cette MR à été suffisamment auditée?