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 ?
1 Like
Ç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
1 Like
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.