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 - Una patch di sicurezza non dovrebbero essere gestite (solamente) dal processo 45 di revisione -stable, ma dovrebbe seguire le procedure descritte in 46 :ref:`Documentation/translations/it_IT/admin-guide/security-bugs.rst <it_securitybugs>`. 47 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 la patch ha bisogno di qualche modifica per essere 94applicata ad un kernel più vecchio (per esempio, perché nel frattempo l'API è 95cambiata). 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 - Alla fine del ciclo di revisione tutte le patch che hanno ricevuto l'ACK 171 verranno aggiunte per il prossimo rilascio -stable, e successivamente 172 questo nuovo rilascio verrà fatto. 173 - Le patch di sicurezza verranno accettate nei sorgenti -stable direttamente 174 dalla squadra per la sicurezza del kernel, e non passerà per il normale 175 ciclo di revisione. Contattate la suddetta squadra per maggiori dettagli 176 su questa procedura. 177 178Sorgenti 179-------- 180 181 - La coda delle patch, sia quelle già applicate che in fase di revisione, 182 possono essere trovate al seguente indirizzo: 183 184 https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git 185 186 - Il rilascio definitivo, e marchiato, di tutti i kernel stabili può essere 187 trovato in rami distinti per versione al seguente indirizzo: 188 189 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 190 191 192Comitato per la revisione 193------------------------- 194 195 - Questo comitato è fatto di sviluppatori del kernel che si sono offerti 196 volontari per questo lavoro, e pochi altri che non sono proprio volontari. 197