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- Questa patch o una equivalente deve esistere già nei sorgenti principali di 15 Linux (upstream) 16- Ovviamente dev'essere corretta e verificata. 17- Non dev'essere più grande di 100 righe, incluso il contesto. 18- Deve rispettare le regole scritte in 19 :ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>` 20- Deve correggere un vero baco che causi problemi agli utenti oppure aggiunge 21 un nuovo identificatore di dispositivo. Maggiori dettagli per il primo caso: 22 23 - Corregge un problema come un oops, un blocco, una corruzione di dati, un 24 vero problema di sicurezza, una stranezza hardware, un problema di 25 compilazione (ma non per cose già segnate con CONFIG_BROKEN), o problemi 26 del tipo "oh, questo non va bene". 27 - Problemi importanti riportati dagli utenti di una distribuzione potrebbero 28 essere considerati se correggono importanti problemi di prestazioni o di 29 interattività. Dato che questi problemi non sono così ovvi e la loro 30 correzione ha un'alta probabilità d'introdurre una regressione, 31 dovrebbero essere sottomessi solo dal manutentore della distribuzione 32 includendo un link, se esiste, ad un rapporto su bugzilla, e informazioni 33 aggiuntive sull'impatto che ha sugli utenti. 34 - Non si accettano cose del tipo "Questo potrebbe essere un problema ..." 35 come una teorica sezione critica, senza aver fornito anche una spiegazione 36 su come il baco possa essere sfruttato. 37 - Non deve includere alcuna correzione "banale" (correzioni grammaticali, 38 pulizia dagli spazi bianchi, eccetera). 39 40Procedura per sottomettere patch per i sorgenti -stable 41------------------------------------------------------- 42 43.. note:: 44 Una patch di sicurezza non dovrebbe essere gestita (solamente) dal processo 45 di revisione -stable, ma dovrebbe seguire le procedure descritte in 46 :ref:`Documentation/translations/it_IT/process/security-bugs.rst <it_securitybugs>`. 47 48Ci sono tre opzioni per inviare una modifica per i sorgenti -stable: 49 501. Aggiungi un'etichetta 'stable' alla descrizione della patch al momento della 51 sottomissione per l'inclusione nei sorgenti principali. 522. Chiedere alla squadra "stable" di prendere una patch già applicata sui 53 sorgenti principali 543. Sottomettere una patch alla squadra "stable" equivalente ad una modifica già 55 fatta sui sorgenti principali. 56 57Le seguenti sezioni descrivono con maggiori dettagli ognuna di queste opzioni 58 59L':ref:`it_option_1` è **fortemente** raccomandata; è il modo più facile e 60usato. L':ref:`it_option_2` si usa quando al momento della sottomissione non si 61era pensato di riportare la modifica su versioni precedenti. 62L':ref:`it_option_3` è un'alternativa ai due metodi precedenti quando la patch 63nei sorgenti principali ha bisogno di aggiustamenti per essere applicata su 64versioni precedenti (per esempio a causa di cambiamenti dell'API). 65 66Quando si utilizza l'opzione 2 o 3 è possibile chiedere che la modifica sia 67inclusa in specifiche versioni stabili. In tal caso, assicurarsi che la correzione 68o una equivalente sia applicabile, o già presente in tutti i sorgenti 69stabili più recenti ancora supportati. Questo ha lo scopo di prevenire 70regressioni che gli utenti potrebbero incontrare in seguito durante 71l'aggiornamento, se ad esempio una correzione per 5.19-rc1 venisse 72riportata a 5.10.y, ma non a 5.15.y. 73 74.. _it_option_1: 75 76Opzione 1 77********* 78 79Aggiungete la seguente etichetta nell'area delle firme per far sì che una patch 80che state inviando per l'inclusione nei sorgenti principali venga presa 81automaticamente anche per quelli stabili:: 82 83 Cc: stable@vger.kernel.org 84 85Invece, usate ``Cc: stable@vger.kernel.org`` quando state inviando correzioni 86per vulnerabilità non ancora di pubblico dominio: questo riduce il rischio di 87esporre accidentalmente al pubblico la correzione quando si usa 'git 88send-email', perché i messaggi inviati a quell'indirizzo non vengono inviati da 89nessuna parte. 90 91Una volta che la patch è stata inclusa, verrà applicata anche sui sorgenti 92stabili senza che l'autore o il manutentore del sottosistema debba fare 93qualcosa. 94 95Per lasciare una nota per la squadra "stable", usate commenti in linea in stile 96shell (leggere oltre per maggiori dettagli). 97 98* Specificate i prerequisiti per le patch aggiuntive:: 99 100 Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle 101 Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle 102 Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic 103 Cc: <stable@vger.kernel.org> # 3.3.x 104 Signed-off-by: Ingo Molnar <mingo@elte.hu> 105 106 La sequenza di etichette ha il seguente significato:: 107 108 git cherry-pick a1f84a3 109 git cherry-pick 1b9508f 110 git cherry-pick fd21073 111 git cherry-pick <this commit> 112 113 Notate che per una serie di patch non dovere elencare come necessarie tutte 114 le patch della serie stessa. Per esempio se avete la seguente serie:: 115 116 patch1 117 patch2 118 119 dove patch2 dipende da patch1, non dovete elencare patch1 come requisito per 120 patch2 se avete già menzionato patch1 per l'inclusione in "stable" 121 122* Evidenziate le patch che hanno dei requisiti circa la versione del kernel:: 123 124 Cc: <stable@vger.kernel.org> # 3.3.x 125 126 L'etichetta ha il seguente significato:: 127 128 git cherry-pick <this commit> 129 130 per ogni sorgente "-stable" che inizia con la versione indicata. 131 132 Notate che queste etichette non sono necessarie se la squadre "stable" può 133 dedurre la versione dalle etichette Fixes: 134 135* Ritardare l'inclusione di patch:: 136 Cc: <stable@vger.kernel.org> # after -rc3 137 138* Evidenziare problemi noti:: 139 140 Cc: <stable@vger.kernel.org> # see patch description, needs adjustments for <= 6.3 141 142Esiste un'ulteriore variante per l'etichetta "stable" che permette di comunicare 143allo strumento di *backporting* di ignorare un cambiamento:: 144 145 Cc: <stable+noautosel@kernel.org> # reason goes here, and must be present 146 147 148.. _it_option_2: 149 150Opzione 2 151********* 152 153Se la patch è già stata inclusa nei sorgenti Linux, inviate una mail a 154stable@vger.kernel.org includendo: il titolo della patch, l'identificativo 155del commit, il perché pensate che debba essere applicata, e in quali versioni 156del kernel la vorreste vedere. 157 158.. _it_option_3: 159 160Opzione 3 161********* 162 163Dopo aver verificato che rispetta le regole descritte in precedenza, inviata la 164patch a stable@vger.kernel.org facendo anche menzione delle versioni nella quale 165si vorrebbe applicarla. Nel farlo, dovete annotare nel changelog 166l'identificativo del commit nei sorgenti principali, così come la versione del 167kernel nel quale vorreste vedere la patch.:: 168 169 commit <sha1> upstream. 170 171o in alternativa:: 172 173 [ Upstream commit <sha1> ] 174 175Se la patch inviata devia rispetto all'originale presente nei sorgenti 176principali (per esempio per adattarsi ad un cambiamento di API), allora questo 177dev'essere giustificato e dettagliato in modo chiaro nella descrizione. 178 179Dopo la sottomissione 180--------------------- 181 182Il mittente riceverà un ACK quando la patch è stata accettata e messa in coda, 183oppure un NAK se la patch è stata rigettata. La risposta potrebbe richiedere 184alcuni giorni in funzione dei piani dei membri della squadra "stable", 185 186Se accettata, la patch verrà aggiunta alla coda -stable per essere revisionata 187dal altri sviluppatori e dal principale manutentore del sottosistema. 188 189Ciclo di una revisione 190---------------------- 191 192- Quando i manutentori -stable decidono di fare un ciclo di revisione, le 193 patch vengono mandate al comitato per la revisione, ai manutentori soggetti 194 alle modifiche delle patch (a meno che il mittente non sia anche il 195 manutentore di quell'area del kernel) e in CC: alla lista di discussione 196 linux-kernel. 197- La commissione per la revisione ha 48 ore per dare il proprio ACK o NACK 198 alle patch. 199- Se una patch viene rigettata da un membro della commissione, o un membro 200 della lista linux-kernel obietta la bontà della patch, sollevando problemi 201 che i manutentori ed i membri non avevano compreso, allora la patch verrà 202 rimossa dalla coda. 203- Le patch che hanno ricevuto un ACK verranno inviate nuovamente come parte di 204 un rilascio candidato (-rc) al fine di essere verificate dagli sviluppatori e 205 dai testatori. 206- Solitamente si pubblica solo una -rc, tuttavia se si riscontrano problemi 207 importanti, alcune patch potrebbero essere modificate o essere scartate, 208 oppure nuove patch potrebbero essere messe in coda. Dunque, verranno pubblicate 209 nuove -rc e così via finché non si ritiene che non vi siano più problemi. 210- Si può rispondere ad una -rc scrivendo sulla lista di discussione un'email 211 con l'etichetta "Tested-by:". Questa etichetta verrà raccolta ed aggiunta al 212 commit rilascio. 213- Alla fine del ciclo di revisione il nuovo rilascio -stable conterrà tutte le 214 patch che erano in coda e sono state verificate. 215- Le patch di sicurezza verranno accettate nei sorgenti -stable direttamente 216 dalla squadra per la sicurezza del kernel, e non passerà per il normale 217 ciclo di revisione. Contattate la suddetta squadra per maggiori dettagli 218 su questa procedura. 219 220Sorgenti 221-------- 222 223- La coda delle patch, sia quelle già applicate che in fase di revisione, 224 possono essere trovate al seguente indirizzo: 225 226 https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git 227 228- Il rilascio definitivo, e marchiato, di tutti i kernel stabili può essere 229 trovato in rami distinti per versione al seguente indirizzo: 230 231 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git 232 233- I rilasci candidati di tutti i kernel stabili possono essere trovati al 234 seguente indirizzo: 235 236 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/ 237 238 .. warning:: 239 I sorgenti -stable-rc sono un'istantanea dei sorgenti stable-queue e 240 subirà frequenti modifiche, dunque verrà anche trapiantato spesso. 241 Dovrebbe essere usato solo allo scopo di verifica (per esempio in un 242 sistema di CI) 243 244Comitato per la revisione 245------------------------- 246 247- Questo comitato è fatto di sviluppatori del kernel che si sono offerti 248 volontari per questo lavoro, e pochi altri che non sono proprio volontari. 249