Warning

In caso di dubbi sulla correttezza del contenuto di questa traduzione, l’unico riferimento valido è la documentazione ufficiale in inglese. Per maggiori informazioni consultate le avvertenze.

Original:

Documentation/process/stable-kernel-rules.rst

Translator:

Federico Vaga <federico.vaga@vaga.pv.it>

Tutto quello che volevate sapere sui rilasci -stable di Linux

Regole sul tipo di patch che vengono o non vengono accettate nei sorgenti “-stable”:

  • Ovviamente dev’essere corretta e verificata.

  • Non dev’essere più grande di 100 righe, incluso il contesto.

  • Deve correggere una cosa sola.

  • Deve correggere un baco vero che sta disturbando gli utenti (non cose del tipo “Questo potrebbe essere un problema …”).

  • Deve correggere un problema di compilazione (ma non per cose già segnate con CONFIG_BROKEN), un kernel oops, un blocco, una corruzione di dati, un vero problema di sicurezza, o problemi del tipo “oh, questo non va bene”. In pratica, qualcosa di critico.

  • Problemi importanti riportati dagli utenti di una distribuzione potrebbero essere considerati se correggono importanti problemi di prestazioni o di interattività. Dato che questi problemi non sono così ovvi e la loro correzione ha un’alta probabilità d’introdurre una regressione, dovrebbero essere sottomessi solo dal manutentore della distribuzione includendo un link, se esiste, ad un rapporto su bugzilla, e informazioni aggiuntive sull’impatto che ha sugli utenti.

  • Non deve correggere problemi relativi a una “teorica sezione critica”, a meno che non venga fornita anche una spiegazione su come questa si possa verificare.

  • Non deve includere alcuna correzione “banale” (correzioni grammaticali, pulizia dagli spazi bianchi, eccetera).

  • Deve rispettare le regole scritte in Documentation/translations/it_IT/process/submitting-patches.rst

  • Questa patch o una equivalente deve esistere già nei sorgenti principali di Linux

Procedura per sottomettere patch per i sorgenti -stable

Note

Una patch di sicurezza non dovrebbe essere gestita (solamente) dal processo di revisione -stable, ma dovrebbe seguire le procedure descritte in Documentation/translations/it_IT/admin-guide/security-bugs.rst.

Per tutte le altre sottomissioni, scegliere una delle seguenti procedure

Opzione 1

Per far sì che una patch venga automaticamente inclusa nei sorgenti stabili, aggiungete l’etichetta

Cc: stable@vger.kernel.org

nell’area dedicata alla firme. Una volta che la patch è stata inclusa, verrà applicata anche sui sorgenti stabili senza che l’autore o il manutentore del sottosistema debba fare qualcosa.

Opzione 2

Dopo che la patch è stata inclusa nei sorgenti Linux, inviate una mail a stable@vger.kernel.org includendo: il titolo della patch, l’identificativo del commit, il perché pensate che debba essere applicata, e in quale versione del kernel la vorreste vedere.

Opzione 3

Inviata la patch, dopo aver verificato che rispetta le regole descritte in precedenza, a stable@vger.kernel.org. Dovete annotare nel changelog l’identificativo del commit nei sorgenti principali, così come la versione del kernel nel quale vorreste vedere la patch.

L’Opzione 1 è fortemente raccomandata; è il modo più facile e usato. L’Opzione 2 e l’Opzione 3 sono più utili quando, al momento dell’inclusione dei sorgenti principali, si ritiene che non debbano essere incluse anche in quelli stabili (per esempio, perché si crede che si dovrebbero fare più verifiche per eventuali regressioni). L’Opzione 3 è particolarmente utile se una patch dev’essere riportata su una versione precedente (per esempio la patch richiede modifiche a causa di cambiamenti di API).

Notate che per l’Opzione 3, se la patch è diversa da quella nei sorgenti principali (per esempio perché è stato necessario un lavoro di adattamento) allora dev’essere ben documentata e giustificata nella descrizione della patch.

L’identificativo del commit nei sorgenti principali dev’essere indicato sopra al messaggio della patch, così:

commit <sha1> upstream.

In aggiunta, alcune patch inviate attraverso l’Opzione 1 potrebbero dipendere da altre che devo essere incluse. Questa situazione può essere indicata nel seguente modo nell’area dedicata alle firme:

Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle
Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle
Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic
Cc: <stable@vger.kernel.org> # 3.3.x
Signed-off-by: Ingo Molnar <mingo@elte.hu>

La sequenza di etichette ha il seguente significato:

git cherry-pick a1f84a3
git cherry-pick 1b9508f
git cherry-pick fd21073
git cherry-pick <this commit>

Inoltre, alcune patch potrebbero avere dei requisiti circa la versione del kernel. Questo può essere indicato usando il seguente formato nell’area dedicata alle firme:

Cc: <stable@vger.kernel.org> # 3.3.x

L’etichetta ha il seguente significato:

git cherry-pick <this commit>

per ogni sorgente “-stable” che inizia con la versione indicata.

Dopo la sottomissione:

  • Il mittente riceverà un ACK quando la patch è stata accettata e messa in coda, oppure un NAK se la patch è stata rigettata. A seconda degli impegni degli sviluppatori, questa risposta potrebbe richiedere alcuni giorni.

  • Se accettata, la patch verrà aggiunta alla coda -stable per essere revisionata dal altri sviluppatori e dal principale manutentore del sottosistema.

Ciclo di una revisione

  • Quando i manutentori -stable decidono di fare un ciclo di revisione, le patch vengono mandate al comitato per la revisione, ai manutentori soggetti alle modifiche delle patch (a meno che il mittente non sia anche il manutentore di quell’area del kernel) e in CC: alla lista di discussione linux-kernel.

  • La commissione per la revisione ha 48 ore per dare il proprio ACK o NACK alle patch.

  • Se una patch viene rigettata da un membro della commissione, o un membro della lista linux-kernel obietta la bontà della patch, sollevando problemi che i manutentori ed i membri non avevano compreso, allora la patch verrà rimossa dalla coda.

  • Le patch che hanno ricevuto un ACK verranno inviate nuovamente come parte di un rilascio candidato (-rc) al fine di essere verificate dagli sviluppatori e dai testatori.

  • Solitamente si pubblica solo una -rc, tuttavia se si riscontrano problemi importanti, alcune patch potrebbero essere modificate o essere scartate, oppure nuove patch potrebbero essere messe in coda. Dunque, verranno pubblicate nuove -rc e così via finché non si ritiene che non vi siano più problemi.

  • Si può rispondere ad una -rc scrivendo sulla lista di discussione un’email con l’etichetta “Tested-by:”. Questa etichetta verrà raccolta ed aggiunta al commit rilascio.

  • Alla fine del ciclo di revisione il nuovo rilascio -stable conterrà tutte le patch che erano in coda e sono state verificate.

  • Le patch di sicurezza verranno accettate nei sorgenti -stable direttamente dalla squadra per la sicurezza del kernel, e non passerà per il normale ciclo di revisione. Contattate la suddetta squadra per maggiori dettagli su questa procedura.

Sorgenti

Comitato per la revisione

  • Questo comitato è fatto di sviluppatori del kernel che si sono offerti volontari per questo lavoro, e pochi altri che non sono proprio volontari.