Linux -stable release rules

-stable tree가 받는 patch

• 동일하거나 동등한 fix가 Linux mainline upstream에 이미 있어야 한다.
• 명백히 올바르고 test된 변경이어야 한다.
• Context를 포함해 100 line보다 크면 안 된다.
• Documentation/process/submitting-patches.rst의 제출 규칙을 따라야 한다.
• 실제 user가 겪는 bug를 고치거나 device ID만 추가하는 변경이어야 한다.
• Oops, hang, data corruption, 실제 security issue, hardware quirk, CONFIG_BROKEN 이외의 build error처럼 명백히 좋지 않은 문제를 고친다.
• Distribution kernel user가 보고한 뚜렷한 performance 또는 interactivity 문제도 고려할 수 있지만 subtle regression 위험이 높으므로 distribution kernel maintainer가 제출하고 bugzilla link와 user-visible impact를 덧붙여야 한다.
• 악용 또는 실제 발생 경로 설명이 없는 theoretical race처럼 '문제가 될 수 있다'는 추측만으로는 받지 않는다.
• Spelling과 whitespace cleanup처럼 user에게 이익이 없는 trivial fix는 받지 않는다.

.. include:: ../disclaimer-ita.rst

:Original: :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
:Translator: Federico Vaga <[email protected]>

.. _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).

-stable 제출의 세 방식

Security patch는 -stable review만으로 처리하지 않고 Documentation/process/security-bugs.rst의 보안 절차를 따라야 한다.

• Option 1: mainline 제출 patch description에 stable tag를 추가한다. 가장 쉽고 흔하며 강하게 권장된다.
• Option 2: 이미 mainline에 merge된 patch를 stable team이 가져가도록 요청한다. 원 제출 때 backport를 고려하지 못한 경우에 주로 쓴다.
• Option 3: mainline change와 동등하지만 옛 series API에 맞게 조정한 patch를 stable team에 직접 보낸다.

Option 2 또는 3으로 특정 stable series만 지정할 때는 그 fix 또는 동등한 변경이 지원 중인 모든 더 최신 stable tree에도 적용 가능하거나 제출되었거나 이미 들어 있는지 확인한다. 예를 들어 5.10.y에 backport했지만 5.15.y에 빠져 user가 upgrade하면서 regression을 다시 만나는 상황을 막기 위해서다.

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
l'aggiornamento, se ad esempio una correzione per 5.19-rc1 venisse
riportata a 5.10.y, ma non a 5.15.y.

Option 1: mainline patch stable tag

Cc: [email protected]

# unpublished vulnerability
Cc: [email protected]

Mainline patch의 sign-off 영역에 Cc: [email protected]를 넣으면 mainline merge 뒤 stable tree가 자동으로 가져간다. 미공개 취약점 fix는 git send-email을 통해 공개될 위험을 줄이도록 실제 전달되지 않는 [email protected] 주소를 사용한다.

.. _it_option_1:

Opzione 1
*********

Aggiungete la seguente etichetta nell'area delle firme per far sì che una patch
che state inviando per l'inclusione nei sorgenti principali venga presa
automaticamente anche per quelli stabili::

  Cc: [email protected]

Invece, usate ``Cc: [email protected]`` quando state inviando correzioni
per vulnerabilità non ancora di pubblico dominio: questo riduce il rischio di
esporre accidentalmente al pubblico la correzione quando si usa 'git
send-email', perché i messaggi inviati a quell'indirizzo non vengono inviati da
nessuna parte.

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.

Per lasciare una nota per la squadra "stable", usate commenti in linea in stile
shell (leggere oltre per maggiori dettagli).

Cherry-pick prerequisite와 version 조건

Cc: <[email protected]> # 3.3.x: a1f84a3: sched: Check for idle
Cc: <[email protected]> # 3.3.x: 1b9508f: sched: Rate-limit newidle
Cc: <[email protected]> # 3.3.x: fd21073: sched: Fix affinity logic
Cc: <[email protected]> # 3.3.x
Signed-off-by: Ingo Molnar <[email protected]>

Shell-style inline comment로 stable team에 prerequisite 순서를 전달할 수 있다. 예시는 a1f84a3, 1b9508f, fd21073을 차례로 cherry-pick한 뒤 current commit을 적용하라는 뜻이다.

같은 patch series 안에서 stable 표시된 앞 patch에 뒤 patch가 의존한다면 prerequisite로 다시 나열할 필요가 없다.

Cc: <[email protected]> # 3.3.x

Version만 적으면 그 version부터 시작하는 각 stable tree에 current commit을 적용한다. Fixes: tag에서 version을 추론할 수 있으면 이 표기는 필요 없다.

* Specificate i prerequisiti per le patch aggiuntive::

    Cc: <[email protected]> # 3.3.x: a1f84a3: sched: Check for idle
    Cc: <[email protected]> # 3.3.x: 1b9508f: sched: Rate-limit newidle
    Cc: <[email protected]> # 3.3.x: fd21073: sched: Fix affinity logic
    Cc: <[email protected]> # 3.3.x
    Signed-off-by: Ingo Molnar <[email protected]>

  La sequenza di etichette ha il seguente significato::

     git cherry-pick a1f84a3
     git cherry-pick 1b9508f
     git cherry-pick fd21073
     git cherry-pick <this commit>

  Notate che per una serie di patch non dovere elencare come necessarie tutte
  le patch della serie stessa. Per esempio se avete la seguente serie::

     patch1
     patch2

  dove patch2 dipende da patch1, non dovete elencare patch1 come requisito per
  patch2 se avete già menzionato patch1 per l'inclusione in "stable"

* Evidenziate le patch che hanno dei requisiti circa la versione del kernel::

    Cc: <[email protected]> # 3.3.x

  L'etichetta ha il seguente significato::

     git cherry-pick <this commit>

  per ogni sorgente "-stable" che inizia con la versione indicata.

  Notate che queste etichette non sono necessarie se la squadre "stable" può
  dedurre la versione dalle etichette Fixes:

지연, known issue, AUTOSEL 제외

Cc: <[email protected]> # after -rc3
Cc: <[email protected]> # see patch description, needs adjustments for <= 6.3
Cc: <[email protected]> # reason goes here, and must be present

Inline note로 -rc3 이후까지 pick을 미루거나 6.3 이하에 조정이 필요하다는 known issue를 알릴 수 있다. AUTOSEL이나 Fixes: scanner 같은 자동 backport tool이 change를 무시해야 한다면 stable+noautosel 주소를 쓰고 반드시 이유를 적는다.

* Ritardare l'inclusione di patch::
    Cc: <[email protected]> # after -rc3

* Evidenziare problemi noti::

     Cc: <[email protected]> # see patch description, needs adjustments for <= 6.3

Esiste un'ulteriore variante per l'etichetta "stable" che permette di comunicare
allo strumento di *backporting* di ignorare un cambiamento::

     Cc: <[email protected]> # reason goes here, and must be present

Option 2: 이미 mainline인 patch 요청

이미 mainline에 merge된 patch라면 [email protected]에 patch subject, commit ID, stable에 적용해야 하는 이유, 원하는 kernel version을 적어 email을 보낸다.

.. _it_option_2:

Opzione 2
*********

Se la patch è già stata inclusa nei sorgenti Linux, inviate una mail a
[email protected] includendo: il titolo della patch, l'identificativo
del commit, il perché pensate che debba essere applicata, e in quali versioni
del kernel la vorreste vedere.

Option 3: 조정한 backport 제출

앞의 규칙을 충족하는지 확인한 patch를 [email protected]에 보내고 적용할 kernel version을 명시한다. Changelog의 commit text 위에 upstream commit ID를 별도 line으로 기록한다.

commit <sha1> upstream.

# or
[ Upstream commit <sha1> ]

옛 API에 맞추기 위해 original upstream patch와 달라졌다면 차이를 patch description에 매우 명확하게 기록하고 정당화한다.

.. _it_option_3:

Opzione 3
*********

Dopo aver verificato che rispetta le regole descritte in precedenza, inviata la
patch a [email protected] facendo anche menzione delle versioni nella quale
si vorrebbe applicarla. Nel farlo, dovete annotare nel changelog
l'identificativo del commit nei sorgenti principali, così come la versione del
kernel nel quale vorreste vedere la patch.::

    commit <sha1> upstream.

o in alternativa::

    [ Upstream commit <sha1>  ]

Se la patch inviata devia rispetto all'originale presente nei sorgenti
principali (per esempio per adattarsi ad un cambiamento di API), allora questo
dev'essere giustificato e dettagliato in modo chiaro nella descrizione.

제출 이후 ACK와 queue

Patch가 queue에 accept되면 ACK, reject되면 NAK를 받는다. Stable team 일정에 따라 며칠 걸릴 수 있다. Accept된 patch는 다른 developer와 관련 subsystem maintainer가 review하는 stable queue에 들어간다.

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. La risposta potrebbe richiedere
alcuni giorni in funzione dei piani dei membri della squadra "stable",

Se accettata, la patch verrà aggiunta alla coda -stable per essere revisionata
dal altri sviluppatori e dal principale manutentore del sottosistema.

48시간 review cycle과 release candidate

• Stable maintainer가 review cycle을 시작하면 patch를 review committee, 영향받는 영역 maintainer, linux-kernel mailing list에 보낸다. Submitter가 해당 maintainer면 별도 maintainer 전달은 생략한다.
• Review committee는 48시간 안에 ACK 또는 NAK한다.
• Committee member가 reject하거나 linux-kernel 구성원이 새 문제를 제기하면 patch를 queue에서 제거한다.
• ACK된 patch는 -rc release로 다시 게시해 developer와 tester가 시험한다.
• 보통 -rc 하나지만 문제가 남으면 patch를 수정·제거하거나 추가 patch를 넣고 문제가 없어질 때까지 새 -rc를 시험한다.
• Test 결과는 mailing list에 Tested-by: email로 보낼 수 있고 tag는 release commit에 모인다.
• Cycle 끝에 queue의 test된 patch 전체를 포함한 새 stable release를 배포한다.
• Security kernel team이 보낸 security patch는 일반 review cycle을 거치지 않고 stable tree에 직접 accept된다.

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.

Stable queue와 release repository

• 완료 및 진행 중 patch queuehttps://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
• Version별 finalized tagged stable releasehttps://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
• Stable release candidatehttps://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/

linux-stable-rc tree는 stable-queue의 특정 시점 snapshot이며 자주 바뀌고 rebase된다. CI를 포함한 시험 목적으로만 사용한다.

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)

Review committee

Review committee는 이 작업에 자원한 여러 kernel developer와 자원하지 않았지만 참여하게 된 일부 developer로 구성된다.

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.