Hantera ytterligare en PostgreSQL Commitfest

Jag har skrivit om att hantera en PostgreSQL commitfest tidigare.

Under utvecklingscykeln för PostgreSQL 13 gjorde jag det igen. Den här gången använde jag en annan strategi, mest för att jag kände att det fanns en överdriven ansamling av mycket gamla plåster som inte fått tillräckligt med uppmärksamhet. Så förutom buggfixar (som alltid är specialfall) fokuserade jag på patchar som hade stått i kön längre.

En sak jag märkte är att vissa patchar inte hade uppdaterats per feedback, eller per bit-ruttnande, även efter upprepad propping från tidigare commitfest-ansvariga. De flyttas från en commitfest till en annan utan någon annan aktivitet. Några av dessa är från personer som har gått vidare från PostgreSQL-utveckling; andra kan vara övergivna projekt. Enligt min åsikt är det ingen idé att ha dem kvar om inget händer, så jag stängde dem och gav en lista, så att andra kan ta en titt och ta ägarskap om de så önskar. (Ett uppföljande inlägg innehåller lite mer). Min förhoppning är att om någon är intresserad av dessa funktioner, kommer de att plocka upp korrigeringarna och skicka in igen efter att ha behandlat eventuell feedback och bitrutt.

En annan sak som börjar bli vanligt är att många patchar dröjer sig kvar med lite granskning - eller ibland till och med med omfattande granskning kommer de aldrig till den punkt där en committer plockar upp dem. I några av dessa fall var mitt tillvägagångssätt att mana specifika personer som jag trodde kunde hjälpa till med granskningen; i andra fall har jag precis granskat patcharna själv. Ibland tycks det ha varit tillräckligt att bara ställa en fråga för att få andra att delta i diskussionen, så även om ens direkta bidrag är litet har det en användbar större effekt.

Jag anmälde mig också som recensent/kommitter för några patchar själv. Jag var måttligt framgångsrik på det, och slutade med 24 commits och 10 commitfest-inlägg markerade som commited ... eller ungefär 25% av det totala antalet commitfest-inlägg som begåtts. Inte illa, va?

I mitt e-postmeddelande om stängningsrapport lade jag upp den här tabellen:

En sak som är värt att notera är hur "returnerade med feedback" höll sig ganska lågt hela tiden och bara hoppade upp i slutet, och med ett stort antal. En övning som jag föreslår att framtida CFMs gör är att på ett hälsosamt sätt stänga inaktiva, bitruttna plåster i slutet av sitt mandat, istället för att flytta sådana plåster till nästa commitfest. Den senare operationen bör reserveras för patchar som har varit aktiva under CF, eller de som fortfarande gäller, eller de som har väntat på författarna nyligen. Det andra värt att notera är antalet lappar som begåtts … eller snarare hur långsamt det klättrade uppåt. Vissa begåvade distraherades av hjälpa till med att Postgres 12 släpps; andra var mycket aktiva i patchar som inte var del av commitfesten. Jag förväntar mig att flera engagerade kommer att ägna mer uppmärksamhet nästa gång, och då kommer vi att se några faktiska framsteg.

Thomas Munros commitfest-bot är ett ovärderligt verktyg; patchförfattare borde ägna mer uppmärksamhet åt det. Det skulle vara mycket bättre att ha den tjänsten integrerad i vår gemenskaps infrastruktur; Jag tror att det bara kräver lite runda kläder.

Några saker som jag skulle ha velat ha:

• en uppdaterad pg_dump av commitfest-data, för lokal sökning.
• Jag fick dumpningar varje vecka genom att fråga rätt person och skrev några grova frågor. Vi skulle kunna tillhandahålla resultaten av (förbättrade versioner av) sådana frågor som rapporter i apparna, kanske.
• En del förbättrad filtrering i commitfest-appen skulle också vara välkomna.
• Att flytta plåster en masse till nästa CF skulle kunna automatiseras bättre.

Sammantaget var detta en mycket tillfredsställande månad och jag hoppas att den var värdefull för PostgreSQL-utvecklingen. Jag är tacksam för att 2ndQuadrant gav mig möjligheten att ägna månaden åt detta... men trots det ser jag fram emot att återgå till mina vanliga arbetsuppgifter.