Ho già scritto sulla gestione di un commitfest PostgreSQL in precedenza.
Durante il ciclo di sviluppo di PostgreSQL 13, l'ho fatto di nuovo. Questa volta ho usato una strategia diversa, principalmente perché sentivo che c'era un eccessivo accumulo di patch molto vecchie che avevano ricevuto un'attenzione insufficiente. Quindi, a parte le correzioni di bug (che sono sempre casi speciali), mi sono concentrato sulle patch che erano rimaste in coda per più tempo.
Una cosa che ho notato è che alcune patch non sono state aggiornate per feedback, o per bit-rotting, anche dopo ripetute sollecitazioni da parte dei precedenti gestori di commitfest. Vengono spostati da un commitfest all'altro senza altre attività. Alcuni di questi provengono da persone che sono passate dallo sviluppo di PostgreSQL; altri potrebbero essere progetti abbandonati. Secondo me, non ha senso tenerli in giro se non sta succedendo nulla, quindi li ho chiusi e ho fornito un elenco, in modo che gli altri possano dare un'occhiata e assumerne la proprietà se lo desiderano. (Un post di follow-up ne contiene altri). La mia speranza è che se qualcuno è interessato a queste funzionalità, prenda le patch e le invii nuovamente dopo aver affrontato eventuali feedback e bit-rot.
Un'altra cosa che sta diventando comune è che molte patch indugiano con poche revisioni - o talvolta anche con revisioni sostanziali non arrivano mai al punto in cui un committente le raccoglie. In alcuni di questi casi, il mio approccio è stato quello di stimolare persone specifiche che pensavo potessero aiutare con la revisione; in altri casi, ho appena rivisto le patch da solo. A volte, semplicemente porre una domanda sembra essere stato sufficiente per coinvolgere gli altri nella discussione, quindi anche se il proprio contributo diretto è piccolo, ha un effetto utile più ampio.
Mi sono anche iscritto come revisore/committente per alcune patch. Ho avuto un discreto successo in questo, finendo con 24 commit e 10 voci di commitfest contrassegnate come impegnate ... o circa il 25% del numero totale di voci di commitfest impegnate. Non male, eh?
Nella mia e-mail di rapporto di chiusura, ho pubblicato questa tabella:
Stato | settimana1 | settimana2 | settimana3 | settimana4 | finale |
Richiede revisione | 165 | 138 | 116 | 118 | 0 |
In attesa dell'autore | 30 | 44 | 51 | 44 | 0 |
Pronto per il committente | 11 | 5 | 8 | 11 | 0 |
Restituito con feedback | 1 | 4 | 5 | 5 | 28 |
Spostato al prossimo CF | 2 | 4 | 4 | 4 | 191 |
Impegnato | 14 | 23 | 32 | 34 | 42 |
Rifiutato | 1 | 1 | 1 | 1 | 1 |
Ritirato | 4 | 9 | 11 | 11 | 12 |
Una cosa degna di nota è come "restituito con feedback" sia rimasto piuttosto basso per tutto il tempo e sia salito solo alla fine, e con un numero considerevole. Un esercizio che suggerisco ai futuri CFM di fare è chiudere in modo sano le patch inattive e bit-rot alla fine del loro mandato, invece di spostare tali patch al prossimo commitfest. Quest'ultima operazione dovrebbe essere riservata alle patch che sono state attive durante la CF, oa quelle ancora valide, oa quelle che hanno atteso gli autori solo di recente. L'altra cosa degna di nota è il numero di patch commesse... o meglio quanto lentamente si è arrampicato. Alcuni committenti sono stati distratti da aiutare con il rilascio di Postgres 12; altri erano molto attivi in patch che non lo erano parte del commitfest. Mi aspetto che diversi committenti presteranno maggiore attenzione la prossima volta, quindi vedremo dei progressi concreti.
Il bot commitfest di Thomas Munro è uno strumento inestimabile; gli autori di patch dovrebbero prestare maggiore attenzione a questo. Sarebbe molto meglio avere quel servizio integrato nella nostra infrastruttura di community commit; Penso che richieda solo alcune lezioni rotonde.
Alcune cose che mi sarebbe piaciuto avere:
- un pg_dump aggiornato dei dati del commitfest, per query locali.
- Ho ottenuto dump settimanalmente chiedendo alla persona giusta e ho scritto alcune domande grossolane. Potremmo fornire i risultati di (versioni migliorate di) query come i rapporti nelle app, forse.
- Anche alcuni filtri migliorati nell'app commitfest sarebbero i benvenuti.
- L'atto di spostare le patch in massa al prossimo CF potrebbe essere automatizzato meglio.
Tutto sommato, questo è stato un mese molto soddisfacente e spero che sia stato prezioso per lo sviluppo di PostgreSQL. Sono grato che 2ndQuadrant mi abbia dato l'opportunità di trascorrere il mese facendo questo... ma anche così, non vedo l'ora di tornare ai miei doveri regolari.