Als je de ontwikkeling van PostgreSQL de afgelopen jaren hebt gevolgd, heb je waarschijnlijk wel eens gehoord van de term commitfest manager enkele keren. Je weet waarschijnlijk al wat een commitfest is, maar waarom is er een manager? Aangezien ik afgelopen januari veel tijd heb besteed aan het beheren van een, zal ik het uitleggen.
Patch toegepast tijdens commitfest
In wezen is een PostgreSQL-commitfest slechts een verzameling patches die wachten op integratie in de PostgreSQL-codebasis. Het werkingsprincipe van een commitfest is dat elke patch die is verzonden naar pgsql-hackers moet tijdig worden herzien; als de patch eenmaal genoeg is beoordeeld en herzien, is hij kandidaat voor permanente opname in PostgreSQL door een committer.
Wat betreft de commitfest-workflow:elke nieuwe patch begint het leven in de commitfest in de status "needs review"; het kan worden afgesloten als "afgewezen" (het breekbare hart van de auteur breken), "toegewijd" (de dag, of week of maand van de auteur maken), of "teruggegeven met feedback" (waarbij de auteur moet volhouden, wetende wat doen om de patch te verbeteren en hem in een toekomstig commitfest nieuw leven in te blazen). Er is ook een kortstondige status, "wachten op auteur", die wordt gebruikt voor snelle feedback die naar verwachting binnen een paar dagen zal resulteren in een nieuwe versie van de patch als "revisie nodig". Zolang we sommige dingen als "toegewijd" hebben gemarkeerd en auteurs goede feedback krijgen, gaat het goed:PostgreSQL groeit, evolueert en rijpt om de volgende "grote release" te worden.
Tot nu toe zo goed.
Waarom hebben we een manager nodig?
Een commitfest beheren
De oplettende lezer is misschien opgevallen dat er drie groepen mensen bij het proces betrokken zijn:patch-auteurs, recensenten, committers. Er is veel overlap tussen die drie groepen, en daar beginnen de problemen. Om goede beoordelingen op codeniveau te doen, moeten mensen de code begrijpen, en degenen die dat wel doen, schrijven ook hun eigen patches. Aan de andere kant zijn committers slechts recensenten die geacht worden betere vaardigheden te hebben in het vinden en oplossen van code-"problemen". Committers schrijven ook voortdurend hun eigen patches.
Het probleem is dat als een patch-auteur exclusief aan zijn eigen patches blijft werken, hij geen tijd heeft om de patches van anderen te beoordelen of vast te leggen. Dit kan gemakkelijk gebeuren als ze feedback krijgen en meteen aan een andere versie werken wat resulteert in meer feedback; dit creëert een lus die heel lang kan doorgaan. Op een gegeven moment is het eerlijk om te doen dat de auteur de patch van het commitfest laat vallen en werkt aan het beoordelen van de patch van iemand anders; maar omdat iedereen zijn patches erg belangrijk vindt, gebeurt dit zelden spontaan.
Dat is waar de commitfest-manager in beeld komt. Een taak is om de interesse van pgsql-hackers te wekken om patches daadwerkelijk te beoordelen. Meestal is het sturen van openbare e-mails naar de groep voldoende om mensen aan het lezen, discussiëren, testen en nadenken over patches te krijgen. Vaak moeten patch-auteurs eraan worden herinnerd dat ze naar de patches van andere mensen moeten kijken, niet alleen naar die van henzelf. De commitfest-applicatie heeft een handige e-mailinterface die daarvoor kan worden gebruikt. Deze dingen zijn normaal gesproken voldoende om een goede hoeveelheid cross-review te creëren.
Er is een oude, bijna vergeten regel:als een patch-auteur geen beoordelingen doet, kunnen hun patches zonder verdere overweging worden gesloten vanaf het commitfest. Bij mijn weten is dit nooit gebeurd, wat inhoudt dat patch-auteurs in ieder geval tot op zekere hoogte "goede burgers" zijn.
Dus, of het nu door overreding of dwang is, een commitfest-manager kan mensen ertoe brengen patches te beoordelen, wat meestal niet spontaan zou gebeuren, behalve wanneer hackers al samenwerken.
Aan de andere kant laten patch-auteurs hun patches soms zonder updates staan. Een mogelijk antwoord is om ze gewoon te sluiten "teruggestuurd met feedback", maar meestal is het de moeite waard om een auteur aan te sporen een bijgewerkte versie in te dienen.
De commitfest-manager kan ook een groot deel van zijn tijd besteden aan het doen van eigen beoordelingen, en als ze commit-privileges hebben, patches uitvoeren.
Ten slotte is het de verantwoordelijkheid van de commitfest-manager om ervoor te zorgen dat alle patches worden gesloten wanneer de commitfest voorbij is, wat normaal gesproken een maand na het begin zou moeten zijn. Voor patches die feedback hebben gekregen, waarop de auteur heeft gereageerd met een andere versie, is het redelijk om "de patch naar de volgende commitfest te verplaatsen":de belofte van de commitfest (om feedback te geven) is gehouden. Het is echter oneerlijk om dat te doen met patches die geen feedback hebben ontvangen. Het sluiten van commitfests wordt moeilijker als dat gebeurt.
Het commitfest van januari 2016
Deze grafiek illustreert de vastlegging van januari 2016. De gegevens komen uit de wekelijkse status-e-mails die ik heb verzonden:start, week 1, week 2, week 3, week 4, finale.
Je kunt zien dat we begonnen met 85 in de status "needs review" of "ready for committer", wat betekent dat ze wachtten op iemand anders dan de auteur om te handelen. Een week later hadden we nog maar 71 patches voor die statussen:dat betekent dat 14 patches in één week werden verwerkt, wat niet slecht is, want als deze snelheid aanhoudt, betekende dat dat de hele patchwachtrij in slechts 5 weken voorbij zou zijn.
Tijdens die eerste week heb ik echter zes triviale patches gemaakt. Die raken vrij snel op, en de verwachting is dat de snelheid van committen zal afnemen. Gelukkig waren andere committers hard aan het werk en je kunt zien dat het aantal vastgelegde patches vrijwel constant was gedurende de hele periode. Het is waarschijnlijk mogelijk om dit in alle commitfests te bereiken, ervan uitgaande dat de committers de juiste overtuigingskracht hebben.
Het is zichtbaar dat de status "teruggestuurd met feedback" pas aan het einde van het commitfest verscheen. Het zet vrijwel de trend voort die te zien is in de regel "wachten op auteur". Volgens mij is dit oké. Sommige mensen geven er de voorkeur aan dat bepaalde patches in een vroeg stadium worden 'opgestart', zodat de inspanningen worden gericht op de patches die echt kans maken om binnen te komen (een 'triage', zo u wilt). Ik ben daar zelf niet zo zeker van, dus ik heb dat idee hier niet toegepast.
Ik denk dat dit commitfest redelijk succesvol was in het vastleggen van patches; de vooruitgang op dat front was zeker zichtbaar, zo niet noodzakelijk enorm. Ik denk ook dat het enorm succesvol was om ervoor te zorgen dat elke patch-auteur behoorlijk wat discussie kreeg over hun patches. Dus wat mij betreft, ben ik tevreden met het geleverde werk.
Advies aan toekomstige commitfest-managers
Ik denk dat het hebben van wekelijkse statusupdates goede resultaten geeft:het geeft iedereen de indruk dat er iets gebeurt (wat het ook is), en motiveert zowel reviewers als committers om hun werk te doen.
Ik nam ook de aanpak om een paar patches op te sommen die elke keer aandacht nodig hadden - niet elke keer dezelfde patches, maar ik concentreerde me elke keer op een andere set, om ervoor te zorgen dat elke vastgelopen patch ergens een kick kreeg. Dit is subtiel werk:het zou gemakkelijker zijn om gewoon alle patches op te sommen die aandacht nodig hebben, maar als je dat doet, glanzen je ogen over gigantische lijsten en wordt alles nog steeds genegeerd.
Alle meningen die u heeft over hoe het commitfest werd beheerd, worden op prijs gesteld; stuur me een e-mail als je het niet openbaar als commentaar wilt plaatsen. Als je denkt dat de dingen die ik deed niet effectief waren, of als je andere ideeën hebt over wat je moet doen, ben ik bereid te luisteren. Ik kan in de toekomst andere commitfests beheren, als de middelen het toelaten.
Bereid je ten slotte voor op het komende commitfest van maart 2016. Het wordt de laatste commitfest voor 9.6 en ik weet zeker dat er genoeg te doen is voor iedereen. Veel plezier met het beoordelen van de patch!