Se hai seguito lo sviluppo di PostgreSQL negli ultimi anni, probabilmente hai sentito il termine commitfest manager alcune volte. Probabilmente sai già cos'è un commitfest, ma perché c'è un manager? Dato che lo scorso gennaio ho passato molto tempo a gestirne uno, ti spiegherò.
Patch applicata durante il commit
Al centro, un commitfest di PostgreSQL è solo una raccolta di patch in attesa di integrazione nella base di codice di PostgreSQL. Il principio di funzionamento di un commitfest è che ogni patch che è stata inviata a pgsql-hacker deve essere rivisto tempestivamente; una volta rivista e rivista abbastanza volte, la patch è candidata per l'inclusione permanente in PostgreSQL da parte di un committer.
Per quanto riguarda il flusso di lavoro del commitfest:ogni nuova patch inizia la vita nel commitfest nello stato "necessita di revisione"; può essere chiuso come "rifiutato" (spezzare il fragile cuore dell'autore), "impegnato" (facendo il giorno, o settimana o mese dell'autore) o "restituito con feedback" (per cui l'autore deve continuare, sapendo cosa da fare per migliorare la patch e resuscitarla in un futuro commit). C'è anche uno stato di breve durata, "in attesa dell'autore", che viene utilizzato per un rapido feedback che dovrebbe tradursi in una nuova versione della patch di nuovo in pochi giorni poiché "necessita di revisione". Finché abbiamo alcune cose contrassegnate come "impegnate" e gli autori ottengono un buon feedback, le cose stanno andando avanti:PostgreSQL cresce, si evolve e matura per diventare la prossima "versione principale".
Fin qui tutto bene.
Perché abbiamo bisogno di un manager?
Gestione di un commit
Il lettore attento potrebbe aver notato che ci sono tre gruppi di persone coinvolte nel processo:autori di patch, revisori, committer. C'è molta sovrapposizione tra questi tre gruppi, ed è qui che iniziano i problemi. Per fare una buona revisione a livello di codice, le persone devono capire il codice e coloro che lo fanno stanno anche scrivendo le proprie patch. D'altra parte, i committenti sono solo revisori che dovrebbero avere migliori capacità nel trovare e risolvere i "problemi" del codice. Anche i committenti scrivono continuamente le proprie patch.
Il problema è che se un autore di patch continua a lavorare esclusivamente sulle proprie patch, non avrà il tempo di rivedere o eseguire il commit delle patch di altre persone. Ciò può accadere facilmente se ricevono feedback e lavorano immediatamente su un'altra versione ottenendo più feedback; questo crea un ciclo che può durare molto a lungo. Ad un certo punto, la cosa giusta da fare è che l'autore elimini la patch dal commitfest e lavori alla revisione della patch di qualcun altro; ma poiché tutti credono che le loro patch siano molto importanti, questo raramente accade spontaneamente.
È qui che entra in gioco il gestore del commitfest. Un compito è raccogliere l'interesse degli hacker di pgsql per rivedere effettivamente le patch. Il più delle volte, l'invio di e-mail pubbliche al gruppo è sufficiente per indurre le persone a leggere, discutere, testare, pensare alle patch. Spesso è necessario ricordare agli autori delle patch che devono guardare le patch di altre persone, non solo le proprie. L'applicazione commitfest ha una pratica interfaccia di invio di un'e-mail che può essere utilizzata per questo. Queste cose sono normalmente sufficienti per creare una buona quantità di revisione incrociata.
C'è una vecchia regola quasi dimenticata:se un autore di patch non fa revisioni, le sue patch possono essere chiuse dal commitfest senza ulteriori considerazioni. Per quanto ne so, questo non è mai successo, il che va a dire che almeno in una certa misura gli autori di patch sono "buoni cittadini".
Pertanto, sia per persuasione che per coercizione, un gestore di commitfest può indurre le persone a rivedere le patch, cosa che per lo più non si verificherebbe spontaneamente tranne quando gli hacker stanno già lavorando in collaborazione.
D'altra parte, gli autori delle patch a volte lasciano le loro patch in sospeso senza aggiornamenti. Una possibile risposta è semplicemente chiuderli "restituiti con feedback", ma il più delle volte vale la pena spingere un autore a inviare una versione aggiornata.
Il gestore del commitfest può anche dedicare molto tempo a fare revisioni per conto proprio e, se dispone dei privilegi di commit, a eseguire patch.
Infine, è responsabilità del gestore del commitfest assicurarsi che tutte le patch siano chiuse al termine del commitfest, che normalmente dovrebbe essere un mese dopo l'inizio. Per le patch che hanno ricevuto feedback, a cui l'autore ha risposto con un'altra versione, è giusto "spostare la patch al prossimo commitfest":la promessa del commitfest (di dare feedback) è stata mantenuta. Tuttavia, farlo su patch che non hanno ricevuto alcun feedback è ingiusto. La chiusura dei commitfest diventa più difficile quando ciò accade.
L'impegno di gennaio 2016
Questo grafico illustra il commitfest di gennaio 2016. I dati provengono dalle e-mail di stato settimanali che ho inviato:inizio, settimana 1, settimana 2, settimana 3, settimana 4, finale.
Puoi vedere che abbiamo iniziato con 85 in stato "necessita di revisione" o "pronto per il committer", il che significa che stavano aspettando che qualcuno diverso dall'autore agisse. Una settimana dopo eravamo scesi a 71 patch su quegli stati:ciò significa che sono state elaborate 14 patch in una settimana, il che non è male perché, se mantenuto, quel tasso significava che l'intera coda di patch sarebbe stata esaurita in sole 5 settimane in più.
Tuttavia, durante quella prima settimana ho commesso sei banali patch. Quelli si esauriscono abbastanza rapidamente e si prevede che il tasso di commit diminuirà. Fortunatamente, altri committenti hanno lavorato sodo e puoi vedere che il tasso di patch impegnate è stato praticamente costante per l'intero periodo. Probabilmente è possibile ottenere questo risultato in tutti i commitfest, supponendo che venga applicata una persuasione adeguata ai committer.
È visibile che lo stato "restituito con feedback" è apparso solo alla fine del commitfest. Praticamente continua la tendenza vista nella linea "in attesa dell'autore". A mio parere, questo va bene. Alcune persone preferirebbero che alcune patch venissero "avviate" all'inizio, in modo che gli sforzi si concentrino sulle patch che hanno davvero una possibilità di entrare (un "triage", se vuoi). Non ne sono sicuro io stesso, quindi non ho applicato questa idea qui.
Penso che questo commitfest abbia avuto un discreto successo nell'ottenere il commit delle patch; i progressi su quel fronte furono certamente visibili, se non necessariamente enormi. Penso anche che sia stato un enorme successo nell'assicurare che ogni autore di patch ricevesse una discreta quantità di discussione sulle proprie patch. Quindi, da parte mia, sono soddisfatto del lavoro svolto.
Consigli ai futuri gestori di commitfest
Penso che avere aggiornamenti di stato settimanali dia buoni risultati:dà a tutti l'impressione che qualcosa stia accadendo (cosa che sta accadendo), motivando sia i revisori che i committenti a svolgere il proprio lavoro.
Inoltre, ho adottato l'approccio di elencare alcune patch che richiedono attenzione ogni volta - non le stesse patch ogni volta, ma piuttosto mi sono concentrato su un set diverso ogni volta, per assicurarmi che ogni patch in stallo avesse un calcio da qualche parte. Questo è un lavoro sottile:sarebbe più facile elencare solo tutte le patch che richiedono attenzione, ma se lo fai, gli occhi si spalancano su elenchi giganteschi e tutto continua a essere ignorato.
Qualsiasi opinione che hai su come è stato gestito il commitfest sarebbe apprezzata; per favore mandami un'e-mail se non vuoi pubblicarlo pubblicamente come commento. Se pensi che le cose che ho fatto siano state inefficaci, o se hai altre idee su cosa fare, sono disposto ad ascoltarti. Potrei gestire altri impegni in futuro, risorse permettendo.
Infine, preparati per il prossimo commitfest di marzo 2016. Sarà l'ultimo commitfest per 9.6 e sono sicuro che ci sarà molto da fare per tutti. Buona revisione della patch!
