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