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 - Se la patch contiene modifiche a dei file nelle cartelle net/ o drivers/net, 45 allora seguite le linee guida descritte in 46 :ref:`Documentation/translations/it_IT/networking/netdev-FAQ.rst <it_netdev-FAQ>`; 47 ma solo dopo aver verificato al seguente indirizzo che la patch non sia 48 già in coda: 49 https://patchwork.kernel.org/bundle/netdev/stable/?state=* 50 - Una patch di sicurezza non dovrebbero essere gestite (solamente) dal processo 51 di revisione -stable, ma dovrebbe seguire le procedure descritte in 52 :ref:`Documentation/translations/it_IT/admin-guide/security-bugs.rst <it_securitybugs>`. 53 54 55Per tutte le altre sottomissioni, scegliere una delle seguenti procedure 56------------------------------------------------------------------------ 57 58.. _it_option_1: 59 60Opzione 1 61********* 62 63Per far sì che una patch venga automaticamente inclusa nei sorgenti stabili, 64aggiungete l'etichetta 65 66.. code-block:: none 67 68 Cc: stable@vger.kernel.org 69 70nell'area dedicata alla firme. Una volta che la patch è stata inclusa, verrà 71applicata anche sui sorgenti stabili senza che l'autore o il manutentore 72del sottosistema debba fare qualcosa. 73 74.. _it_option_2: 75 76Opzione 2 77********* 78 79Dopo che la patch è stata inclusa nei sorgenti Linux, inviate una mail a 80stable@vger.kernel.org includendo: il titolo della patch, l'identificativo 81del commit, il perché pensate che debba essere applicata, e in quale versione 82del kernel la vorreste vedere. 83 84.. _it_option_3: 85 86Opzione 3 87********* 88 89Inviata la patch, dopo aver verificato che rispetta le regole descritte in 90precedenza, a stable@vger.kernel.org. Dovete annotare nel changelog 91l'identificativo del commit nei sorgenti principali, così come la versione 92del kernel nel quale vorreste vedere la patch. 93 94L':ref:`it_option_1` è fortemente raccomandata; è il modo più facile e usato. 95L':ref:`it_option_2` e l':ref:`it_option_3` sono più utili quando, al momento 96dell'inclusione dei sorgenti principali, si ritiene che non debbano essere 97incluse anche in quelli stabili (per esempio, perché si crede che si dovrebbero 98fare più verifiche per eventuali regressioni). L':ref:`it_option_3` è 99particolarmente utile se la patch ha bisogno di qualche modifica per essere 100applicata ad un kernel più vecchio (per esempio, perché nel frattempo l'API è 101cambiata). 102 103Notate che per l':ref:`it_option_3`, se la patch è diversa da quella nei 104sorgenti principali (per esempio perché è stato necessario un lavoro di 105adattamento) allora dev'essere ben documentata e giustificata nella descrizione 106della patch. 107 108L'identificativo del commit nei sorgenti principali dev'essere indicato sopra 109al messaggio della patch, così: 110 111.. code-block:: none 112 113 commit <sha1> upstream. 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 - Alla fine del ciclo di revisione tutte le patch che hanno ricevuto l'ACK 177 verranno aggiunte per il prossimo rilascio -stable, e successivamente 178 questo nuovo rilascio verrà fatto. 179 - Le patch di sicurezza verranno accettate nei sorgenti -stable direttamente 180 dalla squadra per la sicurezza del kernel, e non passerà per il normale 181 ciclo di revisione. Contattate la suddetta squadra per maggiori dettagli 182 su questa procedura. 183 184Sorgenti 185-------- 186 187 - La coda delle patch, sia quelle già applicate che in fase di revisione, 188 possono essere trovate al seguente indirizzo: 189 190 https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git 191 192 - Il rilascio definitivo, e marchiato, di tutti i kernel stabili può essere 193 trovato in rami distinti per versione al seguente indirizzo: 194 195 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 196 197 198Comitato per la revisione 199------------------------- 200 201 - Questo comitato è fatto di sviluppatori del kernel che si sono offerti 202 volontari per questo lavoro, e pochi altri che non sono proprio volontari. 203