0001 .. include:: ../disclaimer-ita.rst
0002
0003 :Original: :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
0004 :Translator: Federico Vaga <federico.vaga@vaga.pv.it>
0005
0006 .. _it_stable_kernel_rules:
0007
0008 Tutto quello che volevate sapere sui rilasci -stable di Linux
0009 ==============================================================
0010
0011 Regole sul tipo di patch che vengono o non vengono accettate nei sorgenti
0012 "-stable":
0013
0014 - Ovviamente dev'essere corretta e verificata.
0015 - Non dev'essere più grande di 100 righe, incluso il contesto.
0016 - Deve correggere una cosa sola.
0017 - Deve correggere un baco vero che sta disturbando gli utenti (non cose del
0018 tipo "Questo potrebbe essere un problema ...").
0019 - Deve correggere un problema di compilazione (ma non per cose già segnate
0020 con CONFIG_BROKEN), un kernel oops, un blocco, una corruzione di dati,
0021 un vero problema di sicurezza, o problemi del tipo "oh, questo non va bene".
0022 In pratica, qualcosa di critico.
0023 - Problemi importanti riportati dagli utenti di una distribuzione potrebbero
0024 essere considerati se correggono importanti problemi di prestazioni o di
0025 interattività. Dato che questi problemi non sono così ovvi e la loro
0026 correzione ha un'alta probabilità d'introdurre una regressione, dovrebbero
0027 essere sottomessi solo dal manutentore della distribuzione includendo un
0028 link, se esiste, ad un rapporto su bugzilla, e informazioni aggiuntive
0029 sull'impatto che ha sugli utenti.
0030 - Non deve correggere problemi relativi a una "teorica sezione critica",
0031 a meno che non venga fornita anche una spiegazione su come questa si
0032 possa verificare.
0033 - Non deve includere alcuna correzione "banale" (correzioni grammaticali,
0034 pulizia dagli spazi bianchi, eccetera).
0035 - Deve rispettare le regole scritte in
0036 :ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`
0037 - Questa patch o una equivalente deve esistere già nei sorgenti principali di
0038 Linux
0039
0040
0041 Procedura per sottomettere patch per i sorgenti -stable
0042 -------------------------------------------------------
0043
0044 .. note::
0045 Una patch di sicurezza non dovrebbe essere gestita (solamente) dal processo
0046 di revisione -stable, ma dovrebbe seguire le procedure descritte in
0047 :ref:`Documentation/translations/it_IT/admin-guide/security-bugs.rst <it_securitybugs>`.
0048
0049 Per tutte le altre sottomissioni, scegliere una delle seguenti procedure
0050 ------------------------------------------------------------------------
0051
0052 .. _it_option_1:
0053
0054 Opzione 1
0055 *********
0056
0057 Per far sì che una patch venga automaticamente inclusa nei sorgenti stabili,
0058 aggiungete l'etichetta
0059
0060 .. code-block:: none
0061
0062 Cc: stable@vger.kernel.org
0063
0064 nell'area dedicata alla firme. Una volta che la patch è stata inclusa, verrà
0065 applicata anche sui sorgenti stabili senza che l'autore o il manutentore
0066 del sottosistema debba fare qualcosa.
0067
0068 .. _it_option_2:
0069
0070 Opzione 2
0071 *********
0072
0073 Dopo che la patch è stata inclusa nei sorgenti Linux, inviate una mail a
0074 stable@vger.kernel.org includendo: il titolo della patch, l'identificativo
0075 del commit, il perché pensate che debba essere applicata, e in quale versione
0076 del kernel la vorreste vedere.
0077
0078 .. _it_option_3:
0079
0080 Opzione 3
0081 *********
0082
0083 Inviata la patch, dopo aver verificato che rispetta le regole descritte in
0084 precedenza, a stable@vger.kernel.org. Dovete annotare nel changelog
0085 l'identificativo del commit nei sorgenti principali, così come la versione
0086 del kernel nel quale vorreste vedere la patch.
0087
0088 L':ref:`it_option_1` è fortemente raccomandata; è il modo più facile e usato.
0089 L':ref:`it_option_2` e l':ref:`it_option_3` sono più utili quando, al momento
0090 dell'inclusione dei sorgenti principali, si ritiene che non debbano essere
0091 incluse anche in quelli stabili (per esempio, perché si crede che si dovrebbero
0092 fare più verifiche per eventuali regressioni). L':ref:`it_option_3` è
0093 particolarmente utile se una patch dev'essere riportata su una versione
0094 precedente (per esempio la patch richiede modifiche a causa di cambiamenti di
0095 API).
0096
0097 Notate che per l':ref:`it_option_3`, se la patch è diversa da quella nei
0098 sorgenti principali (per esempio perché è stato necessario un lavoro di
0099 adattamento) allora dev'essere ben documentata e giustificata nella descrizione
0100 della patch.
0101
0102 L'identificativo del commit nei sorgenti principali dev'essere indicato sopra
0103 al messaggio della patch, così:
0104
0105 .. code-block:: none
0106
0107 commit <sha1> upstream.
0108
0109 In aggiunta, alcune patch inviate attraverso l':ref:`it_option_1` potrebbero
0110 dipendere da altre che devo essere incluse. Questa situazione può essere
0111 indicata nel seguente modo nell'area dedicata alle firme:
0112
0113 .. code-block:: none
0114
0115 Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle
0116 Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle
0117 Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic
0118 Cc: <stable@vger.kernel.org> # 3.3.x
0119 Signed-off-by: Ingo Molnar <mingo@elte.hu>
0120
0121 La sequenza di etichette ha il seguente significato:
0122
0123 .. code-block:: none
0124
0125 git cherry-pick a1f84a3
0126 git cherry-pick 1b9508f
0127 git cherry-pick fd21073
0128 git cherry-pick <this commit>
0129
0130 Inoltre, alcune patch potrebbero avere dei requisiti circa la versione del
0131 kernel. Questo può essere indicato usando il seguente formato nell'area
0132 dedicata alle firme:
0133
0134 .. code-block:: none
0135
0136 Cc: <stable@vger.kernel.org> # 3.3.x
0137
0138 L'etichetta ha il seguente significato:
0139
0140 .. code-block:: none
0141
0142 git cherry-pick <this commit>
0143
0144 per ogni sorgente "-stable" che inizia con la versione indicata.
0145
0146 Dopo la sottomissione:
0147
0148 - Il mittente riceverà un ACK quando la patch è stata accettata e messa in
0149 coda, oppure un NAK se la patch è stata rigettata. A seconda degli impegni
0150 degli sviluppatori, questa risposta potrebbe richiedere alcuni giorni.
0151 - Se accettata, la patch verrà aggiunta alla coda -stable per essere
0152 revisionata dal altri sviluppatori e dal principale manutentore del
0153 sottosistema.
0154
0155
0156 Ciclo di una revisione
0157 ----------------------
0158
0159 - Quando i manutentori -stable decidono di fare un ciclo di revisione, le
0160 patch vengono mandate al comitato per la revisione, ai manutentori soggetti
0161 alle modifiche delle patch (a meno che il mittente non sia anche il
0162 manutentore di quell'area del kernel) e in CC: alla lista di discussione
0163 linux-kernel.
0164 - La commissione per la revisione ha 48 ore per dare il proprio ACK o NACK
0165 alle patch.
0166 - Se una patch viene rigettata da un membro della commissione, o un membro
0167 della lista linux-kernel obietta la bontà della patch, sollevando problemi
0168 che i manutentori ed i membri non avevano compreso, allora la patch verrà
0169 rimossa dalla coda.
0170 - Le patch che hanno ricevuto un ACK verranno inviate nuovamente come parte di
0171 un rilascio candidato (-rc) al fine di essere verificate dagli sviluppatori e
0172 dai testatori.
0173 - Solitamente si pubblica solo una -rc, tuttavia se si riscontrano problemi
0174 importanti, alcune patch potrebbero essere modificate o essere scartate,
0175 oppure nuove patch potrebbero essere messe in coda. Dunque, verranno pubblicate
0176 nuove -rc e così via finché non si ritiene che non vi siano più problemi.
0177 - Si può rispondere ad una -rc scrivendo sulla lista di discussione un'email
0178 con l'etichetta "Tested-by:". Questa etichetta verrà raccolta ed aggiunta al
0179 commit rilascio.
0180 - Alla fine del ciclo di revisione il nuovo rilascio -stable conterrà tutte le
0181 patch che erano in coda e sono state verificate.
0182 - Le patch di sicurezza verranno accettate nei sorgenti -stable direttamente
0183 dalla squadra per la sicurezza del kernel, e non passerà per il normale
0184 ciclo di revisione. Contattate la suddetta squadra per maggiori dettagli
0185 su questa procedura.
0186
0187 Sorgenti
0188 --------
0189
0190 - La coda delle patch, sia quelle già applicate che in fase di revisione,
0191 possono essere trovate al seguente indirizzo:
0192
0193 https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
0194
0195 - Il rilascio definitivo, e marchiato, di tutti i kernel stabili può essere
0196 trovato in rami distinti per versione al seguente indirizzo:
0197
0198 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
0199
0200 - I rilasci candidati di tutti i kernel stabili possono essere trovati al
0201 seguente indirizzo:
0202
0203 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/
0204
0205
0206 .. warning::
0207 I sorgenti -stable-rc sono un'istantanea dei sorgenti stable-queue e
0208 subirà frequenti modifiche, dunque verrà anche trapiantato spesso.
0209 Dovrebbe essere usato solo allo scopo di verifica (per esempio in un
0210 sistema di CI)
0211
0212 Comitato per la revisione
0213 -------------------------
0214
0215 - Questo comitato è fatto di sviluppatori del kernel che si sono offerti
0216 volontari per questo lavoro, e pochi altri che non sono proprio volontari.
