sql >> Database >  >> RDS >> PostgreSQL

Een ander PostgreSQL-commitfest beheren

Ik heb eerder geschreven over het beheren van een PostgreSQL-commitfest.

Tijdens de ontwikkelingscyclus van PostgreSQL 13 deed ik het opnieuw. Deze keer gebruikte ik een andere strategie, vooral omdat ik voelde dat er een overmatige opeenhoping was van zeer oude patches die onvoldoende aandacht hadden gekregen. Dus afgezien van bugfixes (wat altijd speciale gevallen zijn), concentreerde ik me op patches die al langer in de wachtrij stonden.

Een ding dat me opviel, is dat sommige patches niet waren bijgewerkt per feedback, of per bit-rotting, zelfs niet na herhaaldelijk aandringen van eerdere commitfest-managers. Ze worden van het ene commitfest naar het andere verplaatst zonder enige andere activiteit. Sommige daarvan zijn van mensen die zijn overgestapt van PostgreSQL-ontwikkeling; andere kunnen verlaten projecten zijn. Naar mijn mening heeft het geen zin om ze in de buurt te houden als er niets gebeurt, dus heb ik ze gesloten en een lijst verstrekt, zodat anderen kunnen kijken en eigenaar kunnen worden als ze dat willen. (Een vervolgpost bevat er nog meer). Ik hoop dat als iemand geïnteresseerd is in deze functies, ze de patches zullen oppikken en opnieuw zullen indienen nadat ze feedback en bit-rot hebben aangepakt.

Een ander ding dat gebruikelijk wordt, is dat veel patches blijven hangen met weinig recensie - of soms zelfs met een substantiële recensie, ze komen nooit op het punt dat een committer ze oppikt. In sommige van die gevallen was mijn benadering om specifieke mensen te porren waarvan ik dacht dat ze zouden kunnen helpen bij de beoordeling; in andere gevallen heb ik de patches zelf net beoordeeld. Soms lijkt het stellen van een vraag voldoende om anderen bij de discussie te betrekken, dus zelfs als iemands directe bijdrage klein is, heeft het een nuttig groter effect.

Ik heb me ook aangemeld als recensent/committer voor een paar patches. Ik was daarin redelijk succesvol, eindigend met 24 commits en 10 commitfest-inzendingen gemarkeerd als toegewijd … of ongeveer 25% van het totale aantal commitfest-inzendingen die zijn vastgelegd. Niet slecht, toch?

In mijn e-mail met het afsluitingsrapport heb ik deze tabel gepost:

Status week1 week2 week3 week4 finale
Review nodig 165 138 116 118 0
Wachten op auteur 30 44 51 44 0
Klaar voor Committer 11 5 8 11 0
Teruggestuurd met feedback 1 4 5 5 28
Verplaatst naar volgende CF 2 4 4 4 191
Toegewijd 14 23 32 34 42
Geweigerd 1 1 1 1 1
Ingetrokken 4 9 11 11 12

Een ding dat het vermelden waard is, is hoe "geretourneerd met feedback" de hele tijd vrij laag bleef en pas aan het einde omhoog sprong, en met een grote telling. Een oefening die ik toekomstige CFM's aanraad, is om inactieve, bit-rot patches op een gezonde manier te sluiten aan het einde van hun mandaat, in plaats van dergelijke patches naar het volgende commitfest te verplaatsen. De laatste bewerking moet worden gereserveerd voor patches die actief zijn geweest tijdens de CF, of die nog steeds van toepassing zijn, of die pas onlangs op de auteurs wachten. Het andere dat het vermelden waard is, is het aantal patches dat is gepleegd ... of beter gezegd hoe langzaam het omhoog klom. Sommige committers werden afgeleid door helpen met het vrijgeven van Postgre 12; anderen waren erg actief in patches die niet . waren onderdeel van het commitfest. Ik verwacht dat verschillende committers de volgende keer meer aandacht zullen besteden, en dan zullen we daadwerkelijke vooruitgang zien.

De commitfest-bot van Thomas Munro is een hulpmiddel van onschatbare waarde; patch-auteurs zouden daar meer aandacht aan moeten besteden. Het zou veel beter zijn om die service te integreren in onze community-commitfest-infrastructuur; Ik denk dat dat gewoon een paar ronde broeken vereist.

Enkele dingen die ik graag had willen hebben:

  • een bijgewerkte pg_dump van de commitfest-gegevens, voor lokale query's.
  • Ik kreeg wekelijks dumps door het aan de juiste persoon te vragen, en schreef wat grove vragen. We zouden de resultaten van (verbeterde versies van) dergelijke zoekopdrachten misschien kunnen leveren als rapporten in de apps.
  • Enige verbeterde filtering in de commitfest-app zou ook welkom zijn.
  • Het verplaatsen van patches en masse naar volgende CF kan beter worden geautomatiseerd.

Al met al was dit een zeer bevredigende maand en ik hoop dat het waardevol was voor de ontwikkeling van PostgreSQL. Ik ben dankbaar dat 2ndQuadrant me de kans heeft gegeven om dit een maand te doen ... maar toch kijk ik ernaar uit om terug te keren naar mijn normale taken.


  1. hoe cte-waarde toe te wijzen aan variabele

  2. Top 30 SQL Query-interviewvragen die u moet oefenen in 2022

  3. Hoe de maand op te maken in Romeinse cijfers in Oracle

  4. 3 gebieden die baat zullen hebben bij het gebruik van een SQL Server Performance Monitoring Tool