iv/linux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
linux/Documentation/translations/it_IT/process/stable-kernel-rules.rst
Federico Vaga da1d9caf95 doc:it_IT: align Italian documentation 
Translation for the following patches

commit df05c0e9496c ("Documentation: Raise the minimum supported version of LLVM to 11.0.0")
commit 333b11e541fe ("Documentation: Add minimum pahole version")
commit 6d6a8d6a4ed0 ("docs: Update Sphinx requirements")
commit 76ae847497bc ("Documentation: raise minimum supported version of GCC to 5.1")
commit 59c6a716b14b ("Documentation/process/maintainer-pgp-guide: Replace broken link to PGP path finder")
commit 85eafc63d032 ("docs: update file link location")
commit 869f496e1aa6 ("docs: process: submitting-patches: Clarify the Reported-by usage")
commit 6c5ccd24ff17 ("Remove mentions of the Trivial Patch Monkey")
commit aa9b5e0df226 ("Documentation/process: fix self reference")
commit b96ff02ab2be ("Documentation/process: fix a cross reference")
commit 1f57bd42b77c ("docs: submitting-patches: make section about the Link: tag more explicit")
commit a9d85efb25fb ("docs: use the lore redirector everywhere")
commit 31c9d7c82975 ("Documentation/process: Add tip tree handbook")
commit 604370e106cc ("Documentation/process: Add maintainer handbooks section")
commit bf33a9d42d0c ("docs: 5.Posting.rst: describe Fixes: and Link: tags")
commit c04639a7d2fb ("coding-style.rst: trivial: fix location of driver model macros")
commit d5b421fe0282 ("docs: Explain the desired position of function attributes")
commit 3577cdb23b8f ("docs: deprecated.rst: Clarify open-coded arithmetic with literals")
commit db67eb748e7a ("docs: discourage use of list tables")
commit 0e805b118662 ("docs: address some text issues with css/theme support")
commit 135707d3765e ("docs: allow to pass extra DOCS_CSS themes via make")
commit fe450eeb4e6f ("Documentation: in_irq() cleanup")
commit 10855b45a428 ("docs: fix typo in Documentation/kernel-hacking/locking.rst")
commit bc67f1c454fb ("docs: futex: Fix kernel-doc references")
commit abf36fe0be7d ("docs: kernel-hacking: Remove inappropriate text")
commit f35cf1a59e9a ("Documentation: kernel-hacking: minor edits for style")
commit f35cf1a59e9a ("Documentation: kernel-hacking: minor edits for style")
commit 980c3799c500 ("Documentation: kernel-doc: Promote two chapter headings to page title")
commit e1be43d9b5d0 ("overflow: Implement size_t saturating arithmetic helpers")
commit 615f3eea0d5f ("Documentation: add note block surrounding security patch note")
commit 587d39b260c4 ("Documentation: add link to stable release candidate tree")
commit 555d44932c67 ("Documentation: update stable tree link")
commit 88d99e870143 ("Documentation: update stable review cycle documentation")
commit 0c603a5c704f ("Documentation/process: mention patch changelog in review process")
commit 6d5aa418b3bd ("docs: submitting-patches: Fix crossref to 'The canonical patch format'")
commit f1a693994b1c ("Documentation/process: use scripts/get_maintainer.pl on patches")
commit 69ef0920bdd3 ("Docs: Add cpio requirement to changes.rst")
commit 5a5866c28b43 ("Docs: Replace version by 'current' in changes.rst")
commit 9b5a7f4a2a8d ("x86/configs: Add x86 debugging Kconfig fragment plus docs")
commit f1a693994b1c ("Documentation/process: use scripts/get_maintainer.pl on patches")
commit e8c07082a810 ("Kbuild: move to -std=gnu11")

Signed-off-by: Federico Vaga <federico.vaga@vaga.pv.it>
Link: https://lore.kernel.org/r/20220702210820.13118-1-federico.vaga@vaga.pv.it
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2022-07-28 09:34:27 -06:00

217 lines
8.6 KiB
ReStructuredText
Raw Blame History

.. include:: ../disclaimer-ita.rst
:Original: :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
:Translator: Federico Vaga <federico.vaga@vaga.pv.it>
.. _it_stable_kernel_rules:
Tutto quello che volevate sapere sui rilasci -stable di Linux
==============================================================
Regole sul tipo di patch che vengono o non vengono accettate nei sorgenti
"-stable":
- Ovviamente dev'essere corretta e verificata.
- Non dev'essere più grande di 100 righe, incluso il contesto.
- Deve correggere una cosa sola.
- Deve correggere un baco vero che sta disturbando gli utenti (non cose del
tipo "Questo potrebbe essere un problema ...").
- Deve correggere un problema di compilazione (ma non per cose già segnate
con CONFIG_BROKEN), un kernel oops, un blocco, una corruzione di dati,
un vero problema di sicurezza, o problemi del tipo "oh, questo non va bene".
In pratica, qualcosa di critico.
- Problemi importanti riportati dagli utenti di una distribuzione potrebbero
essere considerati se correggono importanti problemi di prestazioni o di
interattività. Dato che questi problemi non sono così ovvi e la loro
correzione ha un'alta probabilità d'introdurre una regressione, dovrebbero
essere sottomessi solo dal manutentore della distribuzione includendo un
link, se esiste, ad un rapporto su bugzilla, e informazioni aggiuntive
sull'impatto che ha sugli utenti.
- Non deve correggere problemi relativi a una "teorica sezione critica",
a meno che non venga fornita anche una spiegazione su come questa si
possa verificare.
- Non deve includere alcuna correzione "banale" (correzioni grammaticali,
pulizia dagli spazi bianchi, eccetera).
- Deve rispettare le regole scritte in
:ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`
- Questa patch o una equivalente deve esistere già nei sorgenti principali di
Linux
Procedura per sottomettere patch per i sorgenti -stable
-------------------------------------------------------
.. note::
Una patch di sicurezza non dovrebbe essere gestita (solamente) dal processo
di revisione -stable, ma dovrebbe seguire le procedure descritte in
:ref:`Documentation/translations/it_IT/admin-guide/security-bugs.rst <it_securitybugs>`.
Per tutte le altre sottomissioni, scegliere una delle seguenti procedure
------------------------------------------------------------------------
.. _it_option_1:
Opzione 1
*********
Per far sì che una patch venga automaticamente inclusa nei sorgenti stabili,
aggiungete l'etichetta
.. code-block:: none
Cc: stable@vger.kernel.org
nell'area dedicata alla firme. Una volta che la patch è stata inclusa, verrà
applicata anche sui sorgenti stabili senza che l'autore o il manutentore
del sottosistema debba fare qualcosa.
.. _it_option_2:
Opzione 2
*********
Dopo che la patch è stata inclusa nei sorgenti Linux, inviate una mail a
stable@vger.kernel.org includendo: il titolo della patch, l'identificativo
del commit, il perché pensate che debba essere applicata, e in quale versione
del kernel la vorreste vedere.
.. _it_option_3:
Opzione 3
*********
Inviata la patch, dopo aver verificato che rispetta le regole descritte in
precedenza, a stable@vger.kernel.org. Dovete annotare nel changelog
l'identificativo del commit nei sorgenti principali, così come la versione
del kernel nel quale vorreste vedere la patch.
L':ref:`it_option_1` è fortemente raccomandata; è il modo più facile e usato.
L':ref:`it_option_2` e l':ref:`it_option_3` sono più utili quando, al momento
dell'inclusione dei sorgenti principali, si ritiene che non debbano essere
incluse anche in quelli stabili (per esempio, perché si crede che si dovrebbero
fare più verifiche per eventuali regressioni). L':ref:`it_option_3` è
particolarmente utile se una patch dev'essere riportata su una versione
precedente (per esempio la patch richiede modifiche a causa di cambiamenti di
API).
Notate che per l':ref:`it_option_3`, se la patch è diversa da quella nei
sorgenti principali (per esempio perché è stato necessario un lavoro di
adattamento) allora dev'essere ben documentata e giustificata nella descrizione
della patch.
L'identificativo del commit nei sorgenti principali dev'essere indicato sopra
al messaggio della patch, così:
.. code-block:: none
commit <sha1> upstream.
In aggiunta, alcune patch inviate attraverso l':ref:`it_option_1` potrebbero
dipendere da altre che devo essere incluse. Questa situazione può essere
indicata nel seguente modo nell'area dedicata alle firme:
.. code-block:: none
Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle
Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle
Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic
Cc: <stable@vger.kernel.org> # 3.3.x
Signed-off-by: Ingo Molnar <mingo@elte.hu>
La sequenza di etichette ha il seguente significato:
.. code-block:: none
git cherry-pick a1f84a3
git cherry-pick 1b9508f
git cherry-pick fd21073
git cherry-pick <this commit>
Inoltre, alcune patch potrebbero avere dei requisiti circa la versione del
kernel. Questo può essere indicato usando il seguente formato nell'area
dedicata alle firme:
.. code-block:: none
Cc: <stable@vger.kernel.org> # 3.3.x
L'etichetta ha il seguente significato:
.. code-block:: none
git cherry-pick <this commit>
per ogni sorgente "-stable" che inizia con la versione indicata.
Dopo la sottomissione:
- Il mittente riceverà un ACK quando la patch è stata accettata e messa in
coda, oppure un NAK se la patch è stata rigettata. A seconda degli impegni
degli sviluppatori, questa risposta potrebbe richiedere alcuni giorni.
- Se accettata, la patch verrà aggiunta alla coda -stable per essere
revisionata dal altri sviluppatori e dal principale manutentore del
sottosistema.
Ciclo di una revisione
----------------------
- Quando i manutentori -stable decidono di fare un ciclo di revisione, le
patch vengono mandate al comitato per la revisione, ai manutentori soggetti
alle modifiche delle patch (a meno che il mittente non sia anche il
manutentore di quell'area del kernel) e in CC: alla lista di discussione
linux-kernel.
- La commissione per la revisione ha 48 ore per dare il proprio ACK o NACK
alle patch.
- Se una patch viene rigettata da un membro della commissione, o un membro
della lista linux-kernel obietta la bontà della patch, sollevando problemi
che i manutentori ed i membri non avevano compreso, allora la patch verrà
rimossa dalla coda.
- Le patch che hanno ricevuto un ACK verranno inviate nuovamente come parte di
un rilascio candidato (-rc) al fine di essere verificate dagli sviluppatori e
dai testatori.
- Solitamente si pubblica solo una -rc, tuttavia se si riscontrano problemi
importanti, alcune patch potrebbero essere modificate o essere scartate,
oppure nuove patch potrebbero essere messe in coda. Dunque, verranno pubblicate
nuove -rc e così via finché non si ritiene che non vi siano più problemi.
- Si può rispondere ad una -rc scrivendo sulla lista di discussione un'email
con l'etichetta "Tested-by:". Questa etichetta verrà raccolta ed aggiunta al
commit rilascio.
- Alla fine del ciclo di revisione il nuovo rilascio -stable conterrà tutte le
patch che erano in coda e sono state verificate.
- Le patch di sicurezza verranno accettate nei sorgenti -stable direttamente
dalla squadra per la sicurezza del kernel, e non passerà per il normale
ciclo di revisione. Contattate la suddetta squadra per maggiori dettagli
su questa procedura.
Sorgenti
--------
- La coda delle patch, sia quelle già applicate che in fase di revisione,
possono essere trovate al seguente indirizzo:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
- Il rilascio definitivo, e marchiato, di tutti i kernel stabili può essere
trovato in rami distinti per versione al seguente indirizzo:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- I rilasci candidati di tutti i kernel stabili possono essere trovati al
seguente indirizzo:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/
.. warning::
I sorgenti -stable-rc sono un'istantanea dei sorgenti stable-queue e
subirà frequenti modifiche, dunque verrà anche trapiantato spesso.
Dovrebbe essere usato solo allo scopo di verifica (per esempio in un
sistema di CI)
Comitato per la revisione
-------------------------
- Questo comitato è fatto di sviluppatori del kernel che si sono offerti
volontari per questo lavoro, e pochi altri che non sono proprio volontari.
Reference in New Issue View Git Blame Copy Permalink