Si vous suivez le développement de PostgreSQL depuis quelques années, vous avez probablement entendu le terme commitfest manager parfois. Vous savez probablement déjà ce qu'est un commitfest, mais pourquoi y a-t-il un manager ? Comme j'ai passé beaucoup de temps en janvier dernier à en gérer un, je vais vous expliquer.
Patch appliqué lors du commitfest
En son cœur, un commitfest PostgreSQL n'est qu'une collection de correctifs en attente d'intégration dans la base de code PostgreSQL. Le principe de fonctionnement d'un commitfest est que chaque patch envoyé à pgsql-hackers doit être révisé en temps opportun ; une fois examiné et révisé suffisamment de fois, le correctif est candidat pour une inclusion permanente dans PostgreSQL par un committer.
En ce qui concerne le flux de travail du commitfest :chaque nouveau patch commence sa vie dans le commitfest dans l'état "nécessite une révision" ; il peut être fermé comme « rejeté » (brisant le cœur fragile de l'auteur), « engagé » (faisant la journée, la semaine ou le mois de l'auteur) ou « retourné avec des commentaires » (par lequel l'auteur doit continuer, sachant ce que faire pour améliorer le patch, et le ressusciter dans un futur commitfest). Il existe également un statut de courte durée, "en attente de l'auteur", qui est utilisé pour des commentaires rapides qui devraient aboutir à une nouvelle version du correctif dans quelques jours, car "nécessite une révision". Tant que nous avons des éléments marqués "engagés" et que les auteurs reçoivent de bons retours, les choses avancent :PostgreSQL grandit, évolue et mûrit pour devenir la prochaine "version majeure".
Jusqu'ici tout va bien.
Pourquoi avons-nous besoin d'un responsable ?
Gérer un commitfest
Le lecteur attentif a peut-être remarqué qu'il y a trois groupes de personnes impliquées dans le processus :les auteurs de correctifs, les réviseurs, les committers. Il y a beaucoup de chevauchement entre ces trois groupes, et c'est là que les problèmes commencent. Pour faire de bonnes révisions au niveau du code, les gens doivent comprendre le code, et ceux qui le font écrivent également leurs propres correctifs. D'un autre côté, les committers ne sont que des réviseurs qui sont censés avoir de meilleures capacités pour trouver et résoudre les « problèmes » de code. Les committers écrivent également leurs propres correctifs tout le temps.
Le problème est que si un auteur de correctifs continue à travailler exclusivement sur ses propres correctifs, il n'aura pas le temps de réviser ou de valider les correctifs d'autres personnes. Cela peut se produire facilement s'ils reçoivent des commentaires et travaillent immédiatement sur une autre version, ce qui entraîne davantage de commentaires ; cela crée une boucle qui peut durer très longtemps. À un moment donné, la chose juste à faire est que l'auteur supprime le patch du commitfest et travaille à réviser le patch de quelqu'un d'autre; mais parce que tout le monde pense que leurs patchs sont très importants, cela se produit rarement spontanément.
C'est là que le responsable du commitfest entre en scène. L'une des tâches consiste à susciter l'intérêt des hackers de pgsql pour qu'ils examinent réellement les correctifs. La plupart du temps, envoyer des e-mails publics au groupe suffit à amener les gens à lire, discuter, tester, réfléchir aux correctifs. Souvent, il faut rappeler aux auteurs de patchs qu'ils doivent regarder les patchs d'autres personnes, pas seulement les leurs. L'application commitfest dispose d'une interface d'envoi d'e-mail pratique qui peut être utilisée à cette fin. Ces choses sont normalement suffisantes pour créer une bonne quantité d'examens croisés.
Il y a une vieille règle presque oubliée :si un auteur de patch ne fait pas de révisions, ses patchs peuvent être fermés du commitfest sans autre considération. À ma connaissance, cela ne s'est jamais produit, ce qui signifie qu'au moins dans une certaine mesure, les auteurs de correctifs sont de « bons citoyens ».
Ainsi, que ce soit par la persuasion ou la coercition, un responsable de commitfest peut amener les gens à revoir les correctifs, ce qui ne se produirait généralement pas spontanément, sauf lorsque les pirates travaillent déjà en coopération.
D'autre part, les auteurs de correctifs laissent parfois leurs correctifs s'attarder sans mises à jour. Une réponse possible consiste simplement à les fermer "retournés avec des commentaires", mais la plupart du temps, cela vaut la peine d'inciter un auteur à soumettre une version mise à jour.
Le responsable du commitfest peut également passer beaucoup de temps à faire ses propres révisions et, s'il a des privilèges de validation, à valider des correctifs.
Enfin, il est de la responsabilité du responsable du commitfest de s'assurer que tous les correctifs sont fermés lorsque le commitfest est terminé, ce qui devrait normalement avoir lieu un mois après son début. Pour les patchs qui ont reçu des retours, auxquels l'auteur a répondu par une autre version, il est juste de "déplacer le patch au prochain commitfest" :la promesse du commitfest (donner un retour) a été tenue. Cependant, faire cela pour des correctifs qui n'ont reçu aucun retour est injuste. La fermeture des commitfests devient alors plus difficile.
Le commitfest de janvier 2016
Ce graphique illustre le commitfest de janvier 2016. Les données proviennent des e-mails de statut hebdomadaires que j'ai envoyés :début, semaine 1, semaine 2, semaine 3, semaine 4, finale.
Vous pouvez voir que nous avons commencé avec 85 dans le statut "nécessite un examen" ou "prêt pour l'engagement", ce qui signifie qu'ils attendaient que quelqu'un d'autre que l'auteur agisse. Une semaine plus tard, nous étions tombés à 71 correctifs sur ces statuts :cela signifie que 14 correctifs ont été traités en une semaine, ce qui n'est pas mal car, s'il était maintenu, ce taux signifiait que toute la file d'attente des correctifs serait terminée en seulement 5 semaines supplémentaires.
Cependant, au cours de cette première semaine, j'ai commis six patchs triviaux. Ceux-ci s'épuisent assez rapidement et le taux d'engagement devrait diminuer. Heureusement, d'autres committers étaient au travail, et vous pouvez voir que le taux de correctifs validés était à peu près constant pendant toute la période. Il est probablement possible d'y parvenir dans tous les commitfests, en supposant qu'une persuasion appropriée soit appliquée aux committers.
Il est visible que le statut "revenu avec retour" n'est apparu qu'à la fin du commitfest. Cela continue à peu près la tendance observée dans la ligne "en attente de l'auteur". À mon avis, c'est correct. Certaines personnes préféreraient que certains correctifs soient "démarrés" dès le début, afin que les efforts soient concentrés sur les correctifs qui ont vraiment une chance d'être intégrés (un "triage", si vous voulez). Je n'en suis pas sûr moi-même, donc je n'ai pas appliqué cette idée ici.
Je pense que ce commitfest a modérément réussi à faire valider des correctifs; les progrès sur ce front étaient certainement visibles, sinon nécessairement énormes. Je pense également que cela a été un énorme succès en veillant à ce que chaque auteur de correctifs ait une bonne quantité de discussions sur ses correctifs. Donc, pour ma part, je suis satisfait du travail effectué.
Conseils aux futurs managers du commitfest
Je pense qu'avoir des mises à jour de statut hebdomadaires donne de bons résultats :cela donne à tout le monde l'impression qu'il se passe quelque chose (ce qui est le cas), ce qui motive à la fois les examinateurs et les committers à faire leur travail.
De plus, j'ai adopté l'approche consistant à répertorier quelques correctifs nécessitant une attention à chaque fois - pas les mêmes correctifs à chaque fois, mais je me suis plutôt concentré sur un ensemble différent à chaque fois, pour m'assurer que chaque correctif bloqué avait un coup de pied quelque part. C'est un travail subtil :il serait plus simple de lister tous les correctifs nécessitant une attention particulière, mais si vous faites cela, les yeux se fixent sur des listes gigantesques et tout continue d'être ignoré.
Toutes les opinions que vous avez sur la façon dont le commitfest a été géré seraient appréciées ; s'il vous plaît écrivez-moi si vous ne voulez pas le publier publiquement en tant que commentaire. Si vous pensez que les choses que j'ai faites étaient inefficaces, ou si vous avez d'autres idées sur ce qu'il faut faire, je suis prêt à vous écouter. Je pourrais gérer d'autres commitfests à l'avenir, si les ressources le permettent.
Enfin, préparez-vous pour le prochain commitfest de mars 2016. Ce sera le dernier commitfest pour la 9.6 et je suis sûr qu'il y aura beaucoup à faire pour tout le monde. Bonne revue de patch !
