Om du har följt PostgreSQL-utvecklingen under de senaste åren har du förmodligen hört termen commitfest manager några gånger. Du vet säkert redan vad en commitfest är, men varför finns det en manager? Eftersom jag tillbringade en hel del tid i januari för att hantera en, ska jag förklara.
Patch applicerad under commitfest
I sitt hjärta är en PostgreSQL commitfest bara en samling patchar som väntar på integration i PostgreSQL-kodbasen. En commitfests arbetsprincip är att varje patch som har skickats till pgsql-hackers måste ses över i tid; när den har granskats och reviderats tillräckligt många gånger, är patchen kandidat för permanent inkludering i PostgreSQL av en committer.
När det gäller commitfest-arbetsflödet:varje ny patch startar livet i commitfesten i tillståndet "behöver granskas"; den kan stängas som "avvisad" (att krossa författarens ömtåliga hjärta), "engagerad" (göra författarens dag, vecka eller månad), eller "återvändas med feedback" (där författaren måste hålla på med det, att veta vad att göra för att förbättra plåstret och återuppliva det i en framtida commitfest). Det finns också en kortlivad status, "väntar på författare", som används för snabb feedback som förväntas resultera i en ny version av patchen om några dagar igen som "behöver granskas". Så länge vi har några saker märkta som "engagerade" och författare får bra feedback, går saker och ting framåt:PostgreSQL växer, utvecklas och mognar för att bli nästa "stora release".
Så långt har det gått bra.
Varför behöver vi en chef?
Hantera en commitfest
Den uppmärksamma läsaren kan ha lagt märke till att det finns tre grupper av personer som är involverade i processen:lappförfattare, recensenter, befattningshavare. Det finns mycket överlappning mellan dessa tre grupper, det är där problemen börjar. För att göra bra recensioner på kodnivå måste folk förstå koden, och de som gör det skriver också sina egna patchar. Å andra sidan är committers bara granskare som ska ha bättre förmåga att hitta och fixa kod "problem". Committers skriver också sina egna patchar hela tiden.
Problemet är att om en patchförfattare fortsätter att arbeta uteslutande med sina egna patchar, kommer de inte att ha tid att granska eller begå andras patchar. Detta kan lätt hända om de får feedback och omedelbart arbetar på en annan version vilket resulterar i mer feedback; detta skapar en loop som kan pågå väldigt länge. Vid något tillfälle är det rättvisa att göra att författaren släpper lappen från commitfesten och arbetar med att granska någon annans lapp; men eftersom alla anser att deras plåster är mycket viktiga, händer detta sällan spontant.
Det är där commitfest-chefen kommer in i bilden. En uppgift är att få intresse från pgsql-hackare att faktiskt granska patchar. För det mesta räcker det att skicka offentliga e-postmeddelanden till gruppen för att få folk att läsa, diskutera, testa, tänka på patchar. Ofta måste lappförfattare påminnas om att de behöver titta på andras lappar, inte bara sina egna. commitfest-applikationen har ett praktiskt skicka-ett-e-postgränssnitt som kan användas för det. Dessa saker är normalt tillräckliga för att skapa en bra mängd korsgranskning.
Det finns en gammal, nästan bortglömd regel:om en patchförfattare inte gör recensioner kan deras patchar stängas av från commitfesten utan ytterligare övervägande. Såvitt jag vet har detta aldrig hänt, vilket innebär att åtminstone i viss mån patchförfattare är "goda medborgare".
Således, oavsett om det är genom övertalning eller tvång, kan en commitfest-manager få människor att granska patchar, vilket oftast inte skulle inträffa spontant förutom när hackare redan arbetar i samarbete.
Å andra sidan lämnar patchförfattare ibland sina patchar för att dröja kvar utan uppdateringar. Ett möjligt svar är att helt enkelt stänga dem "återlämnade med feedback", men oftast är det värt att knuffa en författare att skicka in en uppdaterad version.
commitfest-chefen kan också ägna en hel del tid åt att göra sina egna recensioner, och om de har commit-privilegier, begå patchar.
Slutligen är det commitfest-chefens ansvar att se till att alla patchar är stängda när commitfesten är över, vilket normalt bör vara en månad efter att den startade. För patchar som har fått feedback, som författaren har svarat på med en annan version, är det rimligt att "flytta patchen till nästa commitfest":commitfestens löfte (att ge feedback) har hållits. Men att göra det mot patchar som inte har fått någon feedback är orättvist. Att avsluta commitfests blir svårare när det händer.
Invigningsfesten för januari 2016
Detta diagram illustrerar commitfesten för januari 2016. Uppgifterna kommer från de veckovisa statusmeddelanden jag skickade:start, vecka 1, vecka 2, vecka 3, vecka 4, final.
Du kan se att vi började med 85 i statusen "behöver granskning" eller "redo för committer", vilket betyder att de väntade på att någon annan än författaren skulle agera. En vecka senare var vi nere på 71 patchar på dessa statusar:det betyder att 14 patchar bearbetades på en vecka, vilket inte är dåligt eftersom, om den hölls, innebar den takten att hela patchkön skulle vara över på bara fem veckor till.
Men under den första veckan begick jag sex triviala plåster. De tar slut ganska snabbt och andelen åtaganden förväntas minska. Lyckligtvis jobbade andra hårt på, och du kan se att andelen engagerade patchar var ganska konstant under hela perioden. Det är förmodligen möjligt att uppnå detta i alla commitfests, förutsatt att lämplig övertalning tillämpas på committers.
Det är synligt att statusen "återvänd med feedback" bara dök upp i slutet av commitfesten. Det fortsätter i stort sett trenden som ses i raden "väntar på författare". Enligt min mening är detta okej. Vissa människor skulle föredra att vissa patchar "startas" tidigt, så att ansträngningarna fokuseras på de patchar som verkligen har en chans att komma in (en "triage", om du så vill). Jag är inte säker på det själv, så jag tillämpade inte den idén här.
Jag tror att den här commitfesten var måttligt framgångsrik när det gällde att få patchar committed; framstegen på den fronten var verkligen synliga, om inte nödvändigtvis enorma. Jag tror också att det var oerhört framgångsrikt för att säkerställa att varje patchförfattare fick en del diskussion om sina patchar. Så för min del är jag nöjd med det utförda jobbet.
Råd till framtida commitfest-chefer
Jag tror att veckovisa statusuppdateringar ger bra resultat:det ger alla intrycket av att något händer (vilket det är), vilket motiverar både granskare och engagerade att göra sitt jobb.
Jag tog också tillvägagångssättet att lista några patchar som behöver uppmärksamhet varje gång - inte samma patchar varje gång, utan snarare fokuserade jag på ett annat set varje gång, för att se till att varje patch som stannade fick en kick någonstans. Det här är subtilt arbete:det skulle vara enklare att bara lista alla lappar som behöver uppmärksamhet, men om du gör det blir ögonen glänsande över gigantiska listor och allt fortsätter att ignoreras.
Alla åsikter du har om hur commitfesten sköttes skulle uppskattas; vänligen maila mig om du inte vill publicera det offentligt som en kommentar. Om du tycker att saker jag gjorde var ineffektiva, eller om du har andra idéer om vad du ska göra, är jag villig att lyssna. Jag kan komma att hantera andra commitfests i framtiden, om resurserna tillåter.
Slutligen, förbered dig för den kommande commitfesten i mars 2016. Det kommer att bli den sista commitfesten för 9.6 och jag är säker på att det kommer att finnas mycket att göra för alla. Trevlig patchgranskning!