Sottoporre una patch di Gaia

Ora dovresti aver apportato una modifica e verificato che non abbia introdotto regressioni sul codice di Gaia. Il prossimo passo consiste nel sottoporre la patch sul repository centrale. Viene descritto in questo articolo.

Sottoporre patch a Gaia può risultare un po' complicato in quanto la procedura richiede l'utilizzo di Bugzilla e Github, e la compilazione di alcuni flag speciali in Bugzilla per garantire la corretta sequenza delle azioni.

Sottoporre una patch facilmente con Autolander

Autolander è uno strumento che automaticamente gestisce molti dei passi richiesti per la sottomissione di patch di Gaia (e di altri progetti in cui viene utilizzato), risparmiando tempo e riducendo errori manuali di processo. Autolander integra Bugzilla con il workflow di Github agganciando richieste di pull ai bug automaticamente e altre cose simili. Per utilizzare Autolander:

Primo, apri un bug su Bugzilla per indicare cosa stai facendo, se non ne è già stato aperto uno per la medesima modifica al codice. Dovrai aprirlo come prodotto Firefox OS e dovrai assegnargli un titolo descrittivo.
Ora è il momento di creare una richiesta di pull (pull request, PR in breve) per proporre la tua patch. Se hai seguito la nostra guida dall'inizio, dovresti avere le tue modifiche localmente in un'alberatura duplicata del repository di Gaia a cui hai assegnato un nome univoco. Successivamente, dovrai eseguire il comando git add . e git commit -m 'messaggio di commit'.
'messaggio di commit' dovrà essere sostituito con una stringa che conterrà il numero di bug di Bugzilla, il titolo utilizzato per l'apertura, le informazioni che descrivono cosa fa la patch e chi sta committando. Per esempio:
```
Bug 9999999 - Fix per la risoluzione del bug R=johndoe
```
Deposita il codice sul tuo fork di Gaia su github, quindi crea la richiesta di PR per proporre l'inclusione nella branch main.
Non appena la richiesta di pull verrà aperta, verrà associata al bug tracciato nel titolo della richiesta di PR.
Successivamente, quando sull'allegato verrà posto il flag r+ da un revisore, potrai aggiungere la parola chiave autoland all'interno del campo keywords affinchè il codice venga depositato nel branch master di Gaia (Autolander depositerà il codice, farà il merge della richiesta di PR, farà la commit e segnalerà il bug come fissato). Attualmente questa parte è ancora in revisione, pertanto dovra ancora aggiungere la parola chiave checkin-needed e attendere che il codice venga depositato per tuo conto.

Nota: Autolander esegue i test di integrazione prima di depositare il codice nella master. Se i test di integrazione falliscono, Autolander non depositerà il codice. Autolander esegue alcune regole semplici di validazione quali la verifica della presenza del numero di bug nella richeista di pull e nel messaggio di commit.

Nota: le richieste di pull vengono depositate secondo l'ordine in cui arrivano, in un branch di integrazione e quindi vengono eseguiti i test di integrazione in parallelo su tutte le richieste. Se i test falliscono per una PR, essa viene rigettata, e la branch di integrazione viene ricostruita con le richieste rimanenti. Quando una richiesta passa i test viene depositata nella branch master.

Sottoporre una patch manualmente

In alternativa a Autolander, puoi seguire la seguente procedura per sottoporre una patch di Gaia:

Primo, apri un bug su Bugzilla per indicare cosa stai facendo, se non ne è già stato aperto uno per la medesima modifica. Dovrai aprirlo come prodotto Firefox OS e dovrai assegnargli un titolo descrittivo.
Ora è il momento di creare una richiesta di pull (pull request, PR in breve) per proporre la tua patch. Se hai seguito la nostra guida dall'inizio, dovresti avere le tue modifiche localmente in un'alberatura duplicata del repository di Gaia a cui hai assegnato un nome univoco. Successivamente, dovrai eseguire il comando git add . e git commit -m 'messaggio di commit'.
'messaggio di commit' dovrà essere sostituito con una stringa che conterrà il numero di bug di Bugzilla, il titolo utilizzato per l'apertura, le informazioni che descrivono cosa fa la patch e chi sta committando. Per esempio:
```
Bug 9999999 - Fix per la risoluzione del bug R=johndoe
```
Sottoponi il codice e crea la richiesta di PR.
Aggiungi la URL della PR come allegato del Bug di Bugzilla (segui il link Add an attachment e inserisci la URL del PR come contenuto dell'allegato, aggiungi quindi una breve descrizione).
All'interno della scheda dove hai allegato la richiesta di PR richiedi un revisore per la tua patch. Potrai farlo aggiungendo un flag review: ?, quindi includendo il possessore del modulo che intendi modificare (vedi la pagina dei possessori dei moduli per maggiori dettagli).
Attendi che venga assegnato un revisore e che riveda la tua patch. Il revisore potrebbe aggiungere alcuni commenti e chiederti di apportare modifiche direttamente sulla tua richiesta di PR in github.
Gestisci le richieste del revisore e quindi carica le nuove modifiche al medesimo PR come fatto in precedenza, rimettendo il flag review: ?.
Se vengono approvate, al bug verrà assegnato il flag r+ (significa che è stato rivisto/approvato). Dovrai aggregare tutti i commit in uno (leggi anche la sezione sottostante Suggerimenti_per_il_riallineamento).
Aggiungi la parola chiave checkin-needed nel campo keywords. A questo punto devi solo attendere che qualcuno depositi la tua patch nei sorgenti di Gaia..
Congratulazione il tuo codice è ora parte di Firefox OS!

Nota: vi raccomandiamo di attenervi ad una commit per revisione.

Nota: per ulteriori informazioni sulla sottomissione di patch puoi leggere l'artcolo contributing.md.

Suggerimenti per il riallineamento

Il branch master di Gaia cambia continuamente (molte volte al giorno). Dopo aver creato una patch in 2 ore, potresti trovare che il branch master sia cambiato nel frattempo.

Dal tuo branch di lavoro (per esempio my-code-fix) il primo tentativo di riallineamento potrebbe somigliare al seguente:

git checkout -b my-code-fix-r1
git pull --rebase upstream master

Se non ci sono conflitti, puoi procedere come segue:

git checkout my-code-fix
git pull --rebase upstream master
git branch -D my-code-fix-r1

Se trovi dei conflitti, discutili con gli sviluppatori responsabili delle modifiche che hanno generato i conflitti e una volta risolti ripeti la procedura di riallineamento appena descritta.

Bug di tracciamento di stato e bug di ingegneria

Mozilla ha una figura speciale chiamata Sceriffo (sheriff). Gli sceriffi hanno il compito di effettuare i merge di codice e di manutenere lo stato dei branch. Poichè il numero degli sceriffi è limitato, è difficile per loro gestire tutte le patch imperfette.

Per questo motivo per Firefox OS preferiamo aprire un nuovo bug e quindi gestire una nuova patch ogni qualvolta la patch inviata non lavora come dovrebbe. Ciò potrebbe causare qualche difficoltà nell'interpretazione dello stato del bug in QA e nei team di project management.

Per questo motivo i bugs vengono classificati fra bug di tracciamento di stato (status tracking bugs) e bug di ingegneria (engineering bugs).

I bug di tracciamento di stato vengono identificati tramite una "meta" parola chiave. Un bug di stato può essere riaperto se non soddisfa i criteri di accettazione oppure se fallisce durante lo step di riproduzione.
Un bug di ingegneria dovrebbe essere riaperto solo se fallisce un test automatico o la parch non è corretta. Se una patch fissa il bug solo parzialmente, dovresti chiudere il bug a utilizzare il campo "see also" per referenziare il bug originale e descrivere il punto di fallimento.

Nota: Se si tartta di un bug "user story", il project manager dorvebbe scrivere nel campo user story la storia e i criteri di accettazione.

Come recuperare se accidentalmente carichi una patch su un bug di tracciamento di stato

Se ti succede, non andare in panico. Se accidentalmente sottoponi una patch, ricevi un review+, la sottoponi sul trunk, o viene riportato che non è risolutiva per nulla, segui le seguenti istruzioni:

Premi "Clone this bug" in alto a destra dell'interfaccia utente di Bugzilla per creare un nuovo bug copiando la maggior parte dei campi originali. Verifiche che i campi whiteboard, keyword, e STR/user story siano stati copiati nel nuovo bug.
Imposta il nuovo bug come bloccato dal vecchio bug. Il nuovo bug sarà di tipo bug di tracciamento di stato.
Utiliza il flag needinfo per avvisare il project manager del cambiamento di stato. Puoi trovare gli indirizzi email dei differenti project managers di Firefox OS sul nostro Wiki.
Crea un nuovo bug di ingegneria per descrivere lo step che fallisce o il criterio di accettazione. Inoltre utilizza il nuovo bug per bloccare il bug di tracciamento.
Infine prova a sviluppare una fix per il nuovo bug. Felice hacking!

Applicare patch su vecchi branch

Potresti trovare differenti tag di versione associati a bug. Se vuoi applicare patch a vecchi branch di Firefox OS, verifica che soddisfino le regole di sottomissione. Puoi trovare maggiori dettagli nel seguente aricolo B2G Landing.