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 109In aggiunta, alcune patch inviate attraverso l':ref:`it_option_1` potrebbero 110dipendere da altre che devo essere incluse. Questa situazione può essere 111indicata nel seguente modo nell'area dedicata alle firme: 112 113.. code-block:: none 114 115 Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle 116 Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle 117 Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic 118 Cc: <stable@vger.kernel.org> # 3.3.x 119 Signed-off-by: Ingo Molnar <mingo@elte.hu> 120 121La sequenza di etichette ha il seguente significato: 122 123.. code-block:: none 124 125 git cherry-pick a1f84a3 126 git cherry-pick 1b9508f 127 git cherry-pick fd21073 128 git cherry-pick <this commit> 129 130Inoltre, alcune patch potrebbero avere dei requisiti circa la versione del 131kernel. Questo può essere indicato usando il seguente formato nell'area 132dedicata alle firme: 133 134.. code-block:: none 135 136 Cc: <stable@vger.kernel.org> # 3.3.x 137 138L'etichetta ha il seguente significato: 139 140.. code-block:: none 141 142 git cherry-pick <this commit> 143 144per ogni sorgente "-stable" che inizia con la versione indicata. 145 146Dopo la sottomissione: 147 148 - Il mittente riceverà un ACK quando la patch è stata accettata e messa in 149 coda, oppure un NAK se la patch è stata rigettata. A seconda degli impegni 150 degli sviluppatori, questa risposta potrebbe richiedere alcuni giorni. 151 - Se accettata, la patch verrà aggiunta alla coda -stable per essere 152 revisionata dal altri sviluppatori e dal principale manutentore del 153 sottosistema. 154 155 156Ciclo di una revisione 157---------------------- 158 159 - Quando i manutentori -stable decidono di fare un ciclo di revisione, le 160 patch vengono mandate al comitato per la revisione, ai manutentori soggetti 161 alle modifiche delle patch (a meno che il mittente non sia anche il 162 manutentore di quell'area del kernel) e in CC: alla lista di discussione 163 linux-kernel. 164 - La commissione per la revisione ha 48 ore per dare il proprio ACK o NACK 165 alle patch. 166 - Se una patch viene rigettata da un membro della commissione, o un membro 167 della lista linux-kernel obietta la bontà della patch, sollevando problemi 168 che i manutentori ed i membri non avevano compreso, allora la patch verrà 169 rimossa dalla coda. 170 - Le patch che hanno ricevuto un ACK verranno inviate nuovamente come parte di 171 un rilascio candidato (-rc) al fine di essere verificate dagli sviluppatori e 172 dai testatori. 173 - Solitamente si pubblica solo una -rc, tuttavia se si riscontrano problemi 174 importanti, alcune patch potrebbero essere modificate o essere scartate, 175 oppure nuove patch potrebbero essere messe in coda. Dunque, verranno pubblicate 176 nuove -rc e così via finché non si ritiene che non vi siano più problemi. 177 - Si può rispondere ad una -rc scrivendo sulla lista di discussione un'email 178 con l'etichetta "Tested-by:". Questa etichetta verrà raccolta ed aggiunta al 179 commit rilascio. 180 - Alla fine del ciclo di revisione il nuovo rilascio -stable conterrà tutte le 181 patch che erano in coda e sono state verificate. 182 - Le patch di sicurezza verranno accettate nei sorgenti -stable direttamente 183 dalla squadra per la sicurezza del kernel, e non passerà per il normale 184 ciclo di revisione. Contattate la suddetta squadra per maggiori dettagli 185 su questa procedura. 186 187Sorgenti 188-------- 189 190 - La coda delle patch, sia quelle già applicate che in fase di revisione, 191 possono essere trovate al seguente indirizzo: 192 193 https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git 194 195 - Il rilascio definitivo, e marchiato, di tutti i kernel stabili può essere 196 trovato in rami distinti per versione al seguente indirizzo: 197 198 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git 199 200 - I rilasci candidati di tutti i kernel stabili possono essere trovati al 201 seguente indirizzo: 202 203 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/ 204 205 206 .. warning:: 207 I sorgenti -stable-rc sono un'istantanea dei sorgenti stable-queue e 208 subirà frequenti modifiche, dunque verrà anche trapiantato spesso. 209 Dovrebbe essere usato solo allo scopo di verifica (per esempio in un 210 sistema di CI) 211 212Comitato per la revisione 213------------------------- 214 215 - Questo comitato è fatto di sviluppatori del kernel che si sono offerti 216 volontari per questo lavoro, e pochi altri che non sono proprio volontari. 217