Esistono revisioni di codice in progetti opensource? Se sì, quali strumenti sono usati per fare questo?

Quasi tutti i progetti open source utilizzano una sorta di flusso di lavoro gatekeeper, in cui una persona o un gruppo di persone deve firmare su tutte le modifiche per entrare nella build ufficiale. Alcuni progetti più grandi, come il kernel Linux, hanno strati di gatekeeper. Invia una modifica a qualcuno che gestisce un'area di un sottosistema, inviano le loro modifiche a qualcuno che gestisce un intero sottosistema e inviano le loro modifiche a Linus Torvalds, che a volte controlla il codice stesso o talvolta si fida dei suoi luogotenenti. Queste recensioni di solito non hanno una struttura formale. È solo qualcuno che controlla il codice prima che venga unito.

Per quanto riguarda gli strumenti, guarda il meccanismo di richiesta di pull su github per un buon esempio. Fai una richiesta di pull e su una pagina web dedicata a quella richiesta le persone fanno commenti e l'autore fa le revisioni finché non è abbastanza buono da accettare. Altri gatekeeper usano semplicemente git per applicare patch dalle mailing list o unire richieste pull da repository pubblici, che è uno dei motivi principali per cui sono stati inventati i gits di DVCS.

I progetti open source hanno spesso (e dovrebbero, se non lo fanno) un insieme chiaramente pubblicato di "linee guida della comunità", che spesso include una descrizione del flusso di lavoro del progetto e il modo in cui i contributi sono accettati (e quindi come vengono testati) , così come il processo per diventare un core committer.

Per quanto riguarda la revisione del codice, di nuovo dipende dalla comunità, ma le linee guida sono spesso chiarite. Alcune linee guida di esempio per i contributi dei non committenti vanno da "codice di lavoro vincente" a "i contributi devono avere una copertura completa del test e documentazione, con test impegnati contemporaneamente al codice" e tutto il resto; a prescindere da queste linee guida, l'unica linea guida implicita è che i core committer riesamineranno tutti i contributi dei non-committer prima di accettarli.

I progetti open source con gruppi di core committer spesso hanno anche riunioni virtuali o un tempo dedicato per discutere di eventuali contributi che potrebbero richiedere set di occhi in più - proprio come il processo SE di più voti ravvicinati da parte degli utenti di una certa reputazione prima di una domanda è chiuso, e la discussione di cose discutibili tramite meta o chat.

Ecco alcuni link rapidi ad alcuni documenti di esempio della comunità per i progetti che conosco meglio, in cui puoi trovare le risposte alla tua domanda specifica per questi progetti (noterai presto un tema):

• Principi della comunità Project Blacklight
• Linee guida per il contributo del codice DSpace
• Guida tecnica dei contributori di Apache

I progetti OSS più grandi avranno un numero di responsabili principali. Quindi immagino che siano de-facto "revisori del codice".

Inoltre, poiché il codice OSS è dalla sua natura aperta a tutti, è probabile che ci sia molta più discussione sul codice che stai scrivendo. Anche se questo potrebbe non essere sotto forma di revisioni formali del codice, scoprirai sicuramente se il tuo codice non è considerato all'altezza per uno specifico progetto OSS.