it_IT/process/stable-kernel-rules.rst

1 .. include:: ../disclaimer-ita.rst
3 :Original: :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
8 Tutto quello che volevate sapere sui rilasci -stable di Linux
11 Regole sul tipo di patch che vengono o non vengono accettate nei sorgenti
12 "-stable":
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
19  - Deve correggere un problema di compilazione (ma non per cose già segnate
21    un vero problema di sicurezza, o problemi del tipo "oh, questo non va bene".
23  - Problemi importanti riportati dagli utenti di una distribuzione potrebbero
25    interattività.  Dato che questi problemi non sono così ovvi e la loro
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
33  - Non deve includere alcuna correzione "banale" (correzioni grammaticali,
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
41 Procedura per sottomettere patch per i sorgenti -stable
42 -------------------------------------------------------
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>`.
50 ------------------------------------------------------------------------
58 aggiungete l'etichetta
60 .. code-block:: none
65 applicata anche sui sorgenti stabili senza che l'autore o il manutentore
74 stable@vger.kernel.org includendo: il titolo della patch, l'identificativo
85 l'identificativo del commit nei sorgenti principali, così come la versione
88 L':ref:`it_option_1` è fortemente raccomandata; è il modo più facile e usato.
89 L':ref:`it_option_2` e l':ref:`it_option_3` sono più utili quando, al momento
90 dell'inclusione dei sorgenti principali, si ritiene che non debbano essere
92 fare più verifiche per eventuali regressioni). L':ref:`it_option_3` è
97 Notate che per l':ref:`it_option_3`, se la patch è diversa da quella nei
102 L'identificativo del commit nei sorgenti principali dev'essere indicato sopra
105 .. code-block:: none
111 .. code-block:: none
115 In aggiunta, alcune patch inviate attraverso l':ref:`it_option_1` potrebbero
119 .. code-block:: none
122      Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle
125      Signed-off-by: Ingo Molnar <mingo@elte.hu>
129 .. code-block:: none
131      git cherry-pick a1f84a3
132      git cherry-pick 1b9508f
133      git cherry-pick fd21073
134      git cherry-pick <this commit>
140 .. code-block:: none
144 L'etichetta ha il seguente significato:
146 .. code-block:: none
148      git cherry-pick <this commit>
150 per ogni sorgente "-stable" che inizia con la versione indicata.
154  - Il mittente riceverà un ACK quando la patch è stata accettata e messa in
157  - Se accettata, la patch verrà aggiunta alla coda -stable per essere
163 ----------------------
165  - Quando i manutentori -stable decidono di fare un ciclo di revisione, le
167    alle modifiche delle patch (a meno che il mittente non sia anche il
169    linux-kernel.
170  - La commissione per la revisione ha 48 ore per dare il proprio ACK o NACK
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à
176  - Le patch che hanno ricevuto un ACK verranno inviate nuovamente come parte di
177    un rilascio candidato (-rc) al fine di essere verificate dagli sviluppatori e
179  - Solitamente si pubblica solo una -rc, tuttavia se si riscontrano problemi
182    nuove -rc e così via finché non si ritiene che non vi siano più problemi.
183  - Si può rispondere ad una -rc scrivendo sulla lista di discussione un'email
184    con l'etichetta "Tested-by:". Questa etichetta verrà raccolta ed aggiunta al
186  - Alla fine del ciclo di revisione il nuovo rilascio -stable conterrà tutte le
188  - Le patch di sicurezza verranno accettate nei sorgenti -stable direttamente
189    dalla squadra per la sicurezza del kernel, e non passerà per il normale
194 --------
196  - La coda delle patch, sia quelle già applicate che in fase di revisione,
199 	https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
201  - Il rilascio definitivo, e marchiato, di tutti i kernel stabili può essere
206  - I rilasci candidati di tutti i kernel stabili possono essere trovati al
209     https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/
213      I sorgenti -stable-rc sono un'istantanea dei sorgenti stable-queue e
219 -------------------------
221  - Questo comitato è fatto di sviluppatori del kernel che si sono offerti
222    volontari per questo lavoro, e pochi altri che non sono proprio volontari.