Documentation/translations/it_IT/process/stable-kernel-rules.rst

   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
   8 Tutto quello che volevate sapere sui rilasci -stable di Linux
   9 ==============================================================
  10
  11 Regole 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
  41 Procedura per sottomettere patch per i sorgenti -stable
  42 -------------------------------------------------------
  43
  44 .. note::
  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>`.
  48
  49 Per tutte le altre sottomissioni, scegliere una delle seguenti procedure
  50 ------------------------------------------------------------------------
  51
  52 .. _it_option_1:
  53
  54 Opzione 1
  55 *********
  56
  57 Per far sì che una patch venga automaticamente inclusa nei sorgenti stabili,
  58 aggiungete l'etichetta
  59
  60 .. code-block:: none
  61
  62      Cc: stable@vger.kernel.org
  63
  64 nell'area dedicata alla firme. Una volta che la patch è stata inclusa, verrà
  65 applicata anche sui sorgenti stabili senza che l'autore o il manutentore
  66 del sottosistema debba fare qualcosa.
  67
  68 .. _it_option_2:
  69
  70 Opzione 2
  71 *********
  72
  73 Dopo che la patch è stata inclusa nei sorgenti Linux, inviate una mail a
  74 stable@vger.kernel.org includendo: il titolo della patch, l'identificativo
  75 del commit, il perché pensate che debba essere applicata, e in quale versione
  76 del kernel la vorreste vedere.
  77
  78 .. _it_option_3:
  79
  80 Opzione 3
  81 *********
  82
  83 Inviata la patch, dopo aver verificato che rispetta le regole descritte in
  84 precedenza, a stable@vger.kernel.org.  Dovete annotare nel changelog
  85 l'identificativo del commit nei sorgenti principali, così come la versione
  86 del kernel nel quale vorreste vedere la patch.
  87
  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
  91 incluse anche in quelli stabili (per esempio, perché si crede che si dovrebbero
  92 fare più verifiche per eventuali regressioni). L':ref:`it_option_3` è
  93 particolarmente utile se una patch dev'essere riportata su una versione
  94 precedente (per esempio la patch richiede modifiche a causa di cambiamenti di
  95 API).
  96
  97 Notate che per l':ref:`it_option_3`, se la patch è diversa da quella nei
  98 sorgenti principali (per esempio perché è stato necessario un lavoro di
  99 adattamento) allora dev'essere ben documentata e giustificata nella descrizione
 100 della patch.
 101
 102 L'identificativo del commit nei sorgenti principali dev'essere indicato sopra
 103 al messaggio della patch, così:
 104
 105 .. code-block:: none
 106
 107     commit <sha1> upstream.
 108
 109 o in alternativa:
 110
 111 .. code-block:: none
 112
 113     [ Upstream commit <sha1>  ]
 114
 115 In aggiunta, alcune patch inviate attraverso l':ref:`it_option_1` potrebbero
 116 dipendere da altre che devo essere incluse. Questa situazione può essere
 117 indicata 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
 127 La 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
 136 Inoltre, alcune patch potrebbero avere dei requisiti circa la versione del
 137 kernel. Questo può essere indicato usando il seguente formato nell'area
 138 dedicata alle firme:
 139
 140 .. code-block:: none
 141
 142      Cc: <stable@vger.kernel.org> # 3.3.x
 143
 144 L'etichetta ha il seguente significato:
 145
 146 .. code-block:: none
 147
 148      git cherry-pick <this commit>
 149
 150 per ogni sorgente "-stable" che inizia con la versione indicata.
 151
 152 Dopo 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
 162 Ciclo 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  - 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
 178    dai testatori.
 179  - Solitamente si pubblica solo una -rc, tuttavia se si riscontrano problemi
 180    importanti, alcune patch potrebbero essere modificate o essere scartate,
 181    oppure nuove patch potrebbero essere messe in coda. Dunque, verranno pubblicate
 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
 185    commit rilascio.
 186  - Alla fine del ciclo di revisione il nuovo rilascio -stable conterrà tutte le
 187    patch che erano in coda e sono state verificate.
 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
 190    ciclo di revisione. Contattate la suddetta squadra per maggiori dettagli
 191    su questa procedura.
 192
 193 Sorgenti
 194 --------
 195
 196  - La coda delle patch, sia quelle già applicate che in fase di revisione,
 197    possono essere trovate al seguente indirizzo:
 198
 199         https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
 200
 201  - Il rilascio definitivo, e marchiato, di tutti i kernel stabili può essere
 202    trovato in rami distinti per versione al seguente indirizzo:
 203
 204         https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
 205
 206  - I rilasci candidati di tutti i kernel stabili possono essere trovati al
 207    seguente indirizzo:
 208
 209     https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/
 210
 211
 212    .. warning::
 213      I sorgenti -stable-rc sono un'istantanea dei sorgenti stable-queue e
 214      subirà frequenti modifiche, dunque verrà anche trapiantato spesso.
 215      Dovrebbe essere usato solo allo scopo di verifica (per esempio in un
 216      sistema di CI)
 217
 218 Comitato per la revisione
 219 -------------------------
 220
 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.