Hvis du har fulgt PostgreSQL-udviklingen i de sidste par år, har du sikkert hørt udtrykket commitfest manager et par gange. Du ved sikkert allerede, hvad en commitfest er, men hvorfor er der en manager? Da jeg brugte en del tid i januar på at administrere en, vil jeg forklare.
Patch anvendt under commitfest
I sit hjerte er en PostgreSQL commitfest blot en samling af patches, der afventer integration i PostgreSQL-kodebasen. En commitfests arbejdsprincip er, at hver patch, der er blevet sendt til pgsql-hackere skal revideres rettidigt; når den er gennemgået og revideret nok gange, er patchen kandidat til permanent inklusion i PostgreSQL af en committer.
Med hensyn til commitfest-arbejdsgangen:hver ny patch starter livet i commitfesten i tilstanden "behov for gennemgang"; det kan lukkes som "afvist" (knuser forfatterens skrøbelige hjerte), "forpligtet" (gør forfatterens dag, uge eller måned) eller "returneret med feedback" (hvorved forfatteren skal blive ved med at vide, hvad at gøre for at forbedre lappen og genoplive den i en fremtidig commitfest). Der er også en kortvarig status, "venter på forfatter", som bruges til hurtig feedback, der forventes at resultere i en ny version af patchen om et par dage igen, da "skal gennemgås". Så længe vi har nogle ting markeret som "committed" og forfattere får god feedback, går tingene fremad:PostgreSQL vokser, udvikler sig og modnes til at blive den næste "major release".
Så langt så godt.
Hvorfor har vi brug for en leder?
Håndtering af en commitfest
Den opmærksomme læser har måske bemærket, at der er tre grupper af mennesker involveret i processen:patch-forfattere, anmeldere, committers. Der er meget overlap mellem de tre grupper, og det er her problemerne begynder. For at lave en god gennemgang på kodeniveau skal folk forstå koden, og de, der gør det, skriver også deres egne patches. På den anden side er committers bare anmeldere, som formodes at have bedre evner til at finde og rette kode-"problemer". Committers skriver også deres egne patches hele tiden.
Problemet er, at hvis en patchforfatter udelukkende arbejder på deres egne patches, vil de ikke have tid til at gennemgå eller begå andres patches. Dette kan nemt ske, hvis de modtager feedback og straks arbejder på en anden version, hvilket resulterer i mere feedback; dette skaber en løkke, der kan fortsætte meget længe. På et tidspunkt er det rimeligt, at forfatteren dropper patchen fra commitfesten og arbejder på at gennemgå en andens patch; men fordi alle mener, at deres plastre er meget vigtige, sker dette sjældent spontant.
Det er her, commitfest-manageren kommer ind i billedet. En opgave er at få interesse fra pgsql-hackere til faktisk at gennemgå patches. Det meste af tiden er det nok at sende offentlige e-mails til gruppen til at få folk til at læse, diskutere, teste, tænke på patches. Ofte skal patchforfattere blive mindet om, at de skal se på andres patches, ikke kun deres egne. commitfest-applikationen har en praktisk send-en-e-mail-grænseflade, som kan bruges til det. Disse ting er normalt tilstrækkelige til at skabe en god mængde krydsgennemgang.
Der er en gammel, næsten glemt regel:Hvis en patchforfatter ikke laver anmeldelser, kan deres patches lukkes fra commitfesten uden yderligere overvejelse. Mig bekendt er dette aldrig sket, hvilket går ud på, at i det mindste til en vis grad er patchforfattere "gode borgere".
Således, hvad enten det er ved overtalelse eller tvang, kan en commitfest-manager få folk til at gennemgå patches, som for det meste ikke ville opstå spontant, undtagen når hackere allerede arbejder i samarbejde.
På den anden side lader patchforfattere nogle gange deres patches blive hængende uden opdateringer. Et muligt svar er blot at lukke dem "returneret med feedback", men det meste af tiden er det værd at skubbe en forfatter til at indsende en opdateret version.
commitfest-manageren kan også bruge en del tid på at lave anmeldelser af deres egne, og hvis de har commit-privilegier, begå patches.
Endelig er det commitfest-lederens ansvar at sikre, at alle patches er lukket, når commitfesten er overstået, hvilket normalt bør være en måned efter den startede. For patches, der har modtaget feedback, som forfatteren har reageret på med en anden version, er det rimeligt at "flytte patchen til næste commitfest":commitfestens løfte (om at give feedback) er blevet overholdt. Det er dog uretfærdigt at gøre det mod patches, der ikke har modtaget feedback. Afslutning af forpligtelsesfester bliver sværere, når det sker.
Forpligtelsesfesten for januar 2016
Dette diagram illustrerer forpligtelsesfesten for januar 2016. Dataene er fra de ugentlige statusmails, jeg sendte:start, uge 1, uge 2, uge 3, uge 4, finale.
Du kan se, at vi startede ud med 85 i status som "behøver gennemgang" eller "klar til committer", hvilket betyder, at de ventede på, at en anden end forfatteren skulle handle. En uge senere var vi nede på 71 patches på disse statusser:Det betyder, at 14 patches blev behandlet på én uge, hvilket ikke er dårligt, for hvis det blev fastholdt, betød den hastighed, at hele patch-køen ville være forbi på kun 5 uger mere.
Men i løbet af den første uge lavede jeg seks trivielle plastre. De løber ud ret hurtigt, og forpligtelsesraten forventes at falde. Heldigvis var andre committers hårdt på arbejde, og du kan se, at antallet af committed patches var stort set konstant i hele perioden. Det er sandsynligvis muligt at opnå dette i alle commitfests, forudsat at passende overtalelse anvendes på committers.
Det er synligt, at "returneret med feedback"-status kun dukkede op i slutningen af commitfesten. Det fortsætter stort set tendensen, der ses i linjen "venter på forfatter". Efter min mening er dette okay. Nogle mennesker vil foretrække, at visse patches bliver "startet" tidligt, så indsatsen fokuseres på de patches, der virkelig har en chance for at komme ind (en "triage", om man vil). Jeg er ikke sikker på det selv, så jeg brugte ikke den idé her.
Jeg tror, at denne commitfest var moderat vellykket med at få patches committed; fremgangen på den front var bestemt synlig, hvis ikke nødvendigvis enorm. Jeg synes også, det var enormt vellykket at sikre, at hver patchforfatter fik en god del diskussion af deres patches. Så for mit vedkommende er jeg tilfreds med det udførte arbejde.
Råd til fremtidige commitfest-ledere
Jeg tror, at det giver gode resultater at have ugentlige statusopdateringer:det giver alle indtryk af, at der sker noget (hvilket det er), hvilket motiverer både anmeldere og committers til at udføre deres arbejde.
Jeg tog også den tilgang til at liste et par patches, der kræver opmærksomhed hver gang - ikke de samme patches hver gang, men snarere fokuserede jeg på et andet sæt hver gang for at sikre, at hver stoppede patch fik et kick et eller andet sted. Dette er subtilt arbejde:det ville være nemmere blot at liste alle patches, der kræver opmærksomhed, men hvis du gør det, vil øjnene glane over gigantiske lister, og alt bliver ved med at blive ignoreret.
Enhver mening du har om hvordan commitfesten blev forvaltet ville blive værdsat; send mig en e-mail, hvis du ikke vil skrive det offentligt som en kommentar. Hvis du synes, at ting, jeg gjorde, var ineffektive, eller hvis du har andre ideer til, hvad du skal gøre, er jeg villig til at lytte. Jeg kan styre andre forpligtelsesfester i fremtiden, hvis ressourcerne tillader det.
Forbered dig endelig på den kommende commitfest i marts 2016. Det bliver den sidste commitfest for 9.6, og jeg er sikker på, at der vil være masser at lave for alle. God fornøjelse med anmeldelse af patch!