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

Source file repositories/reference/linux-study-clean/Documentation/translations/it_IT/process/stable-kernel-rules.rst

File Facts

System
Linux kernel
Corpus path
Documentation/translations/it_IT/process/stable-kernel-rules.rst
Extension
.rst
Size
10595 bytes
Lines
249
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. 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":

- Questa patch o una equivalente deve esistere già nei sorgenti principali di
  Linux (upstream)
- Ovviamente dev'essere corretta e verificata.
- Non dev'essere più grande di 100 righe, incluso il contesto.
- Deve rispettare le regole scritte in
  :ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`
- Deve correggere un vero baco che causi problemi agli utenti oppure aggiunge
  un nuovo identificatore di dispositivo. Maggiori dettagli per il primo caso:

  - Corregge un problema come un oops, un blocco, una corruzione di dati, un
    vero problema di sicurezza, una stranezza hardware, un problema di
    compilazione (ma non per cose già segnate con CONFIG_BROKEN), o problemi
    del tipo "oh, questo non va bene".
  - 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 si accettano cose del tipo "Questo potrebbe essere un problema ..."
    come una teorica sezione critica, senza aver fornito anche una spiegazione
    su come il baco possa essere sfruttato.
  - Non deve includere alcuna correzione "banale" (correzioni grammaticali,
    pulizia dagli spazi bianchi, eccetera).

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/process/security-bugs.rst <it_securitybugs>`.

Ci sono tre opzioni per inviare una modifica per i sorgenti -stable:

1. Aggiungi un'etichetta 'stable' alla descrizione della patch al momento della
   sottomissione per l'inclusione nei sorgenti principali.
2. Chiedere alla squadra "stable" di prendere una patch già applicata sui
   sorgenti principali
3. Sottomettere una patch alla squadra "stable" equivalente ad una modifica già
   fatta sui sorgenti principali.

Le seguenti sezioni descrivono con maggiori dettagli ognuna di queste opzioni

L':ref:`it_option_1` è **fortemente** raccomandata; è il modo più facile e
usato. L':ref:`it_option_2` si usa quando al momento della sottomissione non si
era pensato di riportare la modifica su versioni precedenti.
L':ref:`it_option_3` è un'alternativa ai due metodi precedenti quando la patch
nei sorgenti principali ha bisogno di aggiustamenti per essere applicata su
versioni precedenti (per esempio a causa di cambiamenti dell'API).

Quando si utilizza l'opzione 2 o 3 è possibile chiedere che la modifica sia
inclusa in specifiche versioni stabili. In tal caso, assicurarsi che la correzione
o una equivalente sia applicabile, o già presente in tutti i sorgenti
stabili più recenti ancora supportati. Questo ha lo scopo di prevenire
regressioni che gli utenti potrebbero incontrare in seguito durante

Annotation

Implementation Notes