Gerrit, prima conosciuto come Mondrian, è un __sistema di review__ del codice sviluppato internamente da Google per gestire i suoi progetti _Open Source_ ormai diventati troppo grandi, come __Android__. Nasce dal numero troppo elevato di pull-request, data la dimensione la grande partecipazione al progetto si basa sul concetto di "peer review": tutti gli sviluppatori sono autorizzati a fare review delle proposte di modifica di qualsiasi zona di codice.
Gerrit, prima conosciuto come Mondrian, è un __sistema di review__ del codice sviluppato internamente da Google per gestire i suoi progetti _Open Source_ ormai diventati troppo grandi, come __Android__. Nasce dal numero troppo elevato di pull-request, data la grande partecipazione al progetto, e si basa sul concetto di "peer review": tutti gli sviluppatori sono autorizzati a fare review delle proposte di modifica di qualsiasi zona di codice.
Nel processo di review di Gerrit, i __developer__ possono sottoporre proposte di cambiamento utilizzando un sistema di "patch" che descrive le modifiche apportate al codice.
I __reviewer__, ovvero gli altri sviluppatori del progetto, possono quindi esaminare le patch e decidere se accettarle o rifiutarle.
Una volta che una patch ha ricevuto un numero sufficiente di review positivi, viene automaticamente integrata nel __repository principale autoritativo__ in cui tutti hanno accesso in sola lettura.
Gerrit obbliga a strutturare le modifiche (_changeset_) in un unico commit (tecnica _squash_) al momento dell'accettazione.
Ciò significa che tutte le modifiche apportate devono essere fuse in un unico commit, in modo da rendere più facile la gestione del repository e per evitare la nascita di troppi rami.
Al momento della review, invece, le modifiche rimangono separate in versioni singole, ovvero ogni modifica viene presentata come un commit separato, in modo che i reviewer possano esaminarle più facilmente.
Gerrit obbliga a strutturare le modifiche proposte non come una storia di commit ma come un unico commit (_changeset_) al momento dell'accettazione.
Ciò significa che tutte le modifiche apportate devono essere fuse in un unico commit (sotto git utilizza degli amend), in modo da rendere più facile la gestione del repository e per evitare la nascita di troppi rami.
Al momento della review, invece, le modifiche rimangono separate in versioni singole, ovvero ogni modifica viene presentata come un commit separato (quindi vi è la storia), in modo che i reviewer possano esaminarle più facilmente.
Due figure importanti devono fare parte di questo processo:
...
...
@@ -36,13 +36,14 @@ L'approvatore, che dovrà avere una certa esperienza, dato che non si tratta pi
Se l'approver ritiene che la proposta di modifiche sia valida, può approvarla scrivendo "LGTM" (acronimo di _"Looks Good To Me"_) nei commenti della pull request.
Esiste poi una gerarchia di approver, data dalla loro esperienza e contributo, i cui voti avranno valori diversi, in questo modo è possibile fare una review distribuita migliore,
Esiste poi una gerarchia di approver, data dalla loro esperienza e contributo, i cui voti avranno valori diversi, in questo modo è possibile fare una review distribuita migliore (ad esempio se le modifiche riguardano l'interfaccia grafica, i voti di un esperto di interfacce grafiche avranno un peso maggiore).
## Aggiungere parte sul funzionamento di Gerrit (con le due repo, slide non ancora caricate)
## Architettura

- gerrit è come se fosse composto da due repo
-su una solo fetch, solo lettura
-sulla seconda push
- i reviewer usano la seconda, e la prima viene aggioranta dopo la review
- posso automattizare build e testing
- test non dimostrano la correttezza assoluta, mostrano solo quando malfunziona, è un approccio ottimistico
L'architettura di gerrit è composta da due reposirtory:
-__Authoritative repository__: repository in cui vi è solo il diritto di lettura dall'esterno, mentre è presente il diritto di scrittura solo dall'interno da parte dell'altro repository (submit);
-__Pending Changes__: repository in cui i developer hanno solo diritto in scrittura, mentre i reviewer hanno dei diritti speciali che gli permettono di scaricare le modifiche, valutarle e commentarle.
I developer inviano delle modifiche al repository di pending Changes, da cui i reviewer faranno tutte le verifiche e valuteranno il lavoro proposto.
A questo punto, una volta che una patch raggiunge un certo numero di valutazioni positive verrà migrata sull'authoritative repository (compilando e ricontrollato tutto automaticamente) e i developer potranno vedere le nuove modifiche aggiunte.