Håndtering af endnu en PostgreSQL Commitfest

Jeg har skrevet om at administrere en PostgreSQL commitfest før.

Under PostgreSQL 13-udviklingscyklussen gjorde jeg det igen. Denne gang brugte jeg en anden strategi, mest fordi jeg følte, at der var overdreven ophobning af meget gamle plastre, som ikke havde fået tilstrækkelig opmærksomhed. Så bortset fra fejlrettelser (som altid er særlige tilfælde), fokuserede jeg på patches, der havde stået i køen i længere tid.

En ting, jeg lagde mærke til, er, at nogle patches ikke var blevet opdateret pr. feedback eller pr. bit-rotting, selv efter gentagne tilskyndelser fra tidligere commitfest-managere. De bliver flyttet fra en forpligtelsesfest til en anden uden anden aktivitet. Nogle af dem er fra folk, der er gået videre fra PostgreSQL-udvikling; andre kan være forladte projekter. Efter min mening nytter det ikke noget at beholde dem, hvis der ikke sker noget, så jeg lukkede dem og leverede en liste, så andre kan kigge og tage ejerskab, hvis de ønsker det. (Et opfølgende indlæg indeholder nogle flere). Mit håb er, at hvis nogen er interesseret i disse funktioner, vil de hente patches og indsende dem igen efter at have adresseret enhver feedback og bit-rot.

En anden ting, der er ved at blive almindelig, er, at mange patches dvæler med lidt gennemgang - eller nogle gange endda med omfattende gennemgang, når de aldrig til det punkt, hvor en committer samler dem op. I nogle af disse tilfælde var min tilgang at proppe specifikke personer, som jeg troede kunne hjælpe med anmeldelsen; i andre tilfælde har jeg selv gennemgået patcherne. Nogle gange ser det ud til at blot at stille et spørgsmål har været nok til at få andre involveret i diskussionen, så selvom ens direkte bidrag er lille, har det en nyttig større effekt.

Jeg har også selv tilmeldt mig som anmelder/kommitter for et par patches. Jeg var moderat succesfuld med det, og endte med 24 commits og 10 commitfest-indgange markeret som commited … eller omkring 25 % af det samlede antal commitfest-tilmeldinger. Ikke dårligt, vel?

I min e-mail med lukningsrapporten indsendte jeg denne tabel:

En ting, der er værd at bemærke, er, hvordan "returnerede med feedback" forblev ret lavt hele tiden og først sprang op til allersidst, og med et stort antal. En øvelse, som jeg foreslår, at fremtidige CFM'er gør, er sundt at lukke inaktive, bit-råd-plastre i slutningen af ​​deres mandat, i stedet for at flytte sådanne patches til næste commitfest. Sidstnævnte operation bør reserveres til patches, der har været aktive under CF, eller dem, der stadig gælder, eller dem, der først har ventet på forfatterne for nylig. Den anden ting, der er værd at bemærke, er antallet af begåede patches … eller rettere, hvor langsomt det klatrede op. Nogle forbrydere blev distraheret af hjælpe med at blive frigivet Postgres 12; andre var meget aktive i patches, som ikke var del af commitfesten. Jeg forventer, at flere rådgivere vil være mere opmærksomme næste gang, og så vil vi se nogle faktiske fremskridt.

Thomas Munros commitfest-bot er et uvurderligt værktøj; patch-forfattere bør være mere opmærksomme på det. Det ville være meget bedre at få denne service integreret i vores samfunds commitfest-infrastruktur; Det tror jeg bare kræver nogle runde tuits.

Nogle ting, som jeg gerne ville have:

• en opdateret pg_dump af commitfest-dataene til lokal forespørgsel.
• Jeg fik dumps ugentligt ved at spørge den rigtige person og skrev nogle grove forespørgsler. Vi kunne muligvis levere resultaterne af (forbedrede versioner af) sådanne forespørgsler som rapporter i apps.
• Noget forbedret filtrering i commitfest-appen ville også være velkommen.
• At flytte patches en masse til næste CF kunne automatiseres bedre.

Alt i alt var dette en meget tilfredsstillende måned, og jeg håber, den var værdifuld for PostgreSQL-udvikling. Jeg er taknemmelig for, at 2ndQuadrant gav mig muligheden for at bruge måneden på at gøre dette … men alligevel ser jeg frem til at vende tilbage til mine almindelige pligter.