1.. include:: ../disclaimer-ita.rst 2 3:Original: :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>` 4:Translator: Federico Vaga <federico.vaga@vaga.pv.it> 5 6.. _it_stable_kernel_rules: 7 8Tutto quello che volevate sapere sui rilasci -stable di Linux 9============================================================== 10 11Regole sul tipo di patch che vengono o non vengono accettate nei sorgenti 12"-stable": 13 14 - Ovviamente dev'essere corretta e verificata. 15 - Non dev'essere più grande di 100 righe, incluso il contesto. 16 - Deve correggere una cosa sola. 17 - Deve correggere un baco vero che sta disturbando gli utenti (non cose del 18 tipo "Questo potrebbe essere un problema ..."). 19 - Deve correggere un problema di compilazione (ma non per cose già segnate 20 con CONFIG_BROKEN), un kernel oops, un blocco, una corruzione di dati, 21 un vero problema di sicurezza, o problemi del tipo "oh, questo non va bene". 22 In pratica, qualcosa di critico. 23 - Problemi importanti riportati dagli utenti di una distribuzione potrebbero 24 essere considerati se correggono importanti problemi di prestazioni o di 25 interattività. Dato che questi problemi non sono così ovvi e la loro 26 correzione ha un'alta probabilità d'introdurre una regressione, dovrebbero 27 essere sottomessi solo dal manutentore della distribuzione includendo un 28 link, se esiste, ad un rapporto su bugzilla, e informazioni aggiuntive 29 sull'impatto che ha sugli utenti. 30 - Non deve correggere problemi relativi a una "teorica sezione critica", 31 a meno che non venga fornita anche una spiegazione su come questa si 32 possa verificare. 33 - Non deve includere alcuna correzione "banale" (correzioni grammaticali, 34 pulizia dagli spazi bianchi, eccetera). 35 - Deve rispettare le regole scritte in 36 :ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>` 37 - Questa patch o una equivalente deve esistere già nei sorgenti principali di 38 Linux 39 40 41Procedura per sottomettere patch per i sorgenti -stable 42------------------------------------------------------- 43 44.. note:: 45 Una patch di sicurezza non dovrebbe essere gestita (solamente) dal processo 46 di revisione -stable, ma dovrebbe seguire le procedure descritte in 47 :ref:`Documentation/translations/it_IT/admin-guide/security-bugs.rst <it_securitybugs>`. 48 49Per tutte le altre sottomissioni, scegliere una delle seguenti procedure 50------------------------------------------------------------------------ 51 52.. _it_option_1: 53 54Opzione 1 55********* 56 57Per far sì che una patch venga automaticamente inclusa nei sorgenti stabili, 58aggiungete l'etichetta 59 60.. code-block:: none 61 62 Cc: stable@vger.kernel.org 63 64nell'area dedicata alla firme. Una volta che la patch è stata inclusa, verrà 65applicata anche sui sorgenti stabili senza che l'autore o il manutentore 66del sottosistema debba fare qualcosa. 67 68.. _it_option_2: 69 70Opzione 2 71********* 72 73Dopo che la patch è stata inclusa nei sorgenti Linux, inviate una mail a 74stable@vger.kernel.org includendo: il titolo della patch, l'identificativo 75del commit, il perché pensate che debba essere applicata, e in quale versione 76del kernel la vorreste vedere. 77 78.. _it_option_3: 79 80Opzione 3 81********* 82 83Inviata la patch, dopo aver verificato che rispetta le regole descritte in 84precedenza, a stable@vger.kernel.org. Dovete annotare nel changelog 85l'identificativo del commit nei sorgenti principali, così come la versione 86del kernel nel quale vorreste vedere la patch. 87 88L':ref:`it_option_1` è fortemente raccomandata; è il modo più facile e usato. 89L':ref:`it_option_2` e l':ref:`it_option_3` sono più utili quando, al momento 90dell'inclusione dei sorgenti principali, si ritiene che non debbano essere 91incluse anche in quelli stabili (per esempio, perché si crede che si dovrebbero 92fare più verifiche per eventuali regressioni). L':ref:`it_option_3` è 93particolarmente utile se una patch dev'essere riportata su una versione 94precedente (per esempio la patch richiede modifiche a causa di cambiamenti di 95API). 96 97Notate che per l':ref:`it_option_3`, se la patch è diversa da quella nei 98sorgenti principali (per esempio perché è stato necessario un lavoro di 99adattamento) allora dev'essere ben documentata e giustificata nella descrizione 100della patch. 101 102L'identificativo del commit nei sorgenti principali dev'essere indicato sopra 103al messaggio della patch, così: 104 105.. code-block:: none 106 107 commit <sha1> upstream. 108 109o in alternativa: 110 111.. code-block:: none 112 113 [ Upstream commit <sha1> ] 114 115In aggiunta, alcune patch inviate attraverso l':ref:`it_option_1` potrebbero 116dipendere da altre che devo essere incluse. Questa situazione può essere 117indicata nel seguente modo nell'area dedicata alle firme: 118 119.. code-block:: none 120 121 Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle 122 Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle 123 Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic 124 Cc: <stable@vger.kernel.org> # 3.3.x 125 Signed-off-by: Ingo Molnar <mingo@elte.hu> 126 127La sequenza di etichette ha il seguente significato: 128 129.. code-block:: none 130 131 git cherry-pick a1f84a3 132 git cherry-pick 1b9508f 133 git cherry-pick fd21073 134 git cherry-pick <this commit> 135 136Inoltre, alcune patch potrebbero avere dei requisiti circa la versione del 137kernel. Questo può essere indicato usando il seguente formato nell'area 138dedicata alle firme: 139 140.. code-block:: none 141 142 Cc: <stable@vger.kernel.org> # 3.3.x 143 144L'etichetta ha il seguente significato: 145 146.. code-block:: none 147 148 git cherry-pick <this commit> 149 150per ogni sorgente "-stable" che inizia con la versione indicata. 151 152Dopo la sottomissione: 153 154 - Il mittente riceverà un ACK quando la patch è stata accettata e messa in 155 coda, oppure un NAK se la patch è stata rigettata. A seconda degli impegni 156 degli sviluppatori, questa risposta potrebbe richiedere alcuni giorni. 157 - Se accettata, la patch verrà aggiunta alla coda -stable per essere 158 revisionata dal altri sviluppatori e dal principale manutentore del 159 sottosistema. 160 161 162Ciclo di una revisione 163---------------------- 164 165 - Quando i manutentori -stable decidono di fare un ciclo di revisione, le 166 patch vengono mandate al comitato per la revisione, ai manutentori soggetti 167 alle modifiche delle patch (a meno che il mittente non sia anche il 168 manutentore di quell'area del kernel) e in CC: alla lista di discussione 169 linux-kernel. 170 - La commissione per la revisione ha 48 ore per dare il proprio ACK o NACK 171 alle patch. 172 - Se una patch viene rigettata da un membro della commissione, o un membro 173 della lista linux-kernel obietta la bontà della patch, sollevando problemi 174 che i manutentori ed i membri non avevano compreso, allora la patch verrà 175 rimossa dalla coda. 176 - Le patch che hanno ricevuto un ACK verranno inviate nuovamente come parte di 177 un rilascio candidato (-rc) al fine di essere verificate dagli sviluppatori e 178 dai testatori. 179 - Solitamente si pubblica solo una -rc, tuttavia se si riscontrano problemi 180 importanti, alcune patch potrebbero essere modificate o essere scartate, 181 oppure nuove patch potrebbero essere messe in coda. Dunque, verranno pubblicate 182 nuove -rc e così via finché non si ritiene che non vi siano più problemi. 183 - Si può rispondere ad una -rc scrivendo sulla lista di discussione un'email 184 con l'etichetta "Tested-by:". Questa etichetta verrà raccolta ed aggiunta al 185 commit rilascio. 186 - Alla fine del ciclo di revisione il nuovo rilascio -stable conterrà tutte le 187 patch che erano in coda e sono state verificate. 188 - Le patch di sicurezza verranno accettate nei sorgenti -stable direttamente 189 dalla squadra per la sicurezza del kernel, e non passerà per il normale 190 ciclo di revisione. Contattate la suddetta squadra per maggiori dettagli 191 su questa procedura. 192 193Sorgenti 194-------- 195 196 - La coda delle patch, sia quelle già applicate che in fase di revisione, 197 possono essere trovate al seguente indirizzo: 198 199 https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git 200 201 - Il rilascio definitivo, e marchiato, di tutti i kernel stabili può essere 202 trovato in rami distinti per versione al seguente indirizzo: 203 204 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git 205 206 - I rilasci candidati di tutti i kernel stabili possono essere trovati al 207 seguente indirizzo: 208 209 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/ 210 211 212 .. warning:: 213 I sorgenti -stable-rc sono un'istantanea dei sorgenti stable-queue e 214 subirà frequenti modifiche, dunque verrà anche trapiantato spesso. 215 Dovrebbe essere usato solo allo scopo di verifica (per esempio in un 216 sistema di CI) 217 218Comitato per la revisione 219------------------------- 220 221 - Questo comitato è fatto di sviluppatori del kernel che si sono offerti 222 volontari per questo lavoro, e pochi altri che non sono proprio volontari. 223