Esistono revisioni del codice nei progetti opensource? In tal caso, quali strumenti vengono utilizzati per farlo?

So che c'è una grande spinta per le revisioni del codice nello sviluppo commerciale. Tuttavia, le revisioni del codice sono utilizzate nel software open source o sono basate sulla fiducia? In tal caso, come vengono eseguiti? [È un commit ritardato, "un ambiente pre-commit", esiste uno strumento che consente di inviare la patch a un altro sviluppatore]?

Ci sono progetti che utilizzano revisioni del codice?

Da quanto ho capito, il kernel Linux si basa principalmente sulla fiducia del committer. MySQL si basava sull'approvazione dell'autore principale e sull'impatto sulle prestazioni.

Quasi tutti i progetti open source utilizzano una sorta di flusso di lavoro gatekeeper, in cui una persona o un gruppo di persone deve approvare tutte le modifiche per accedere alla build ufficiale. Alcuni progetti più grandi, come il kernel Linux, hanno livelli di gatekeeper. Inviate 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 rivede il codice da solo o a volte si fida dei suoi luogotenenti. Queste recensioni di solito non hanno una struttura formale. È solo qualcuno che osserva il codice prima che venga unito.

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

I progetti open source spesso hanno (e dovrebbero, in caso contrario) una serie chiaramente definita di "linee guida della comunità", che spesso include una descrizione del flusso di lavoro del progetto e di come i contributi vengono accettati (e quindi come vengono testati), nonché come processo per diventare un committer principale.

Per quanto riguarda la revisione del codice, dipende ancora dalla comunità, ma le linee guida sono spesso chiarite. Alcune linee guida di esempio per i contributi dei non committenti vanno da "vincite del codice di lavoro" a "i contributi devono avere una copertura e una documentazione di prova complete, con prove impegnate contemporaneamente al codice" e tutto il resto; indipendentemente da queste linee guida, l'unica linea guida che è implicita è che i committenti principali rivedranno tutti i contributi dei non committenti prima di accettarli.

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

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

• Progetto principi della comunità Blacklight
• Linee guida per il contributo del codice DSpace
• Guida tecnica per i collaboratori di Apache

I progetti OSS più grandi avranno un certo numero di committer principali. Quindi immagino che siano i "revisori del codice" di fatto.

Inoltre, poiché il codice OSS è per sua natura aperto 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 da zero per un progetto OSS specifico.