Linux kernel 개발에 참여하는 방법

이 문서의 목적

이 문서는 Linux kernel developer가 되는 방법과 Linux kernel development community에서 함께 일하는 방법을 안내하는 종합 문서다. Kernel programming의 기술적 세부 사항 자체는 다루지 않지만, 그 내용을 배우기 위해 어느 방향으로 가야 하는지 알려 준다.

문서 내용이 오래되어 현재 상황과 맞지 않게 되면 문서 맨 아래에 적힌 maintainer에게 patch를 보내 갱신해야 한다.

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

:Original: :ref:`Documentation/process/howto.rst <process_howto>`
:Translator: Alessia Mantegazza <amantegazza@vaga.pv.it>

.. _it_process_howto:

Come partecipare allo sviluppo del kernel Linux
===============================================

Questo è il documento fulcro di quanto trattato sull'argomento.
Esso contiene le istruzioni su come diventare uno sviluppatore
del kernel Linux e spiega come lavorare con la comunità di
sviluppo kernel Linux. Il documento non tratterà alcun aspetto
tecnico relativo alla programmazione del kernel, ma vi aiuterà
indirizzandovi sulla corretta strada.

Se qualsiasi cosa presente in questo documento diventasse obsoleta,
vi preghiamo di inviare le correzioni agli amministratori di questo
file, indicati in fondo al presente documento.

시작하기 전에 필요한 배경

Linux kernel developer가 되고 싶거나 관리자로부터 “이 장치의 Linux driver를 작성하라”는 지시를 받았다면, 이 문서는 그 목표에 이르기 위해 거쳐야 할 절차와 community에서 협업하는 방법을 설명한다. Kernel community가 현재와 같은 방식으로 움직이는 이유도 함께 설명하려 한다.

Kernel은 대부분 C로 작성되며 architecture-dependent 부분 일부는 assembly로 작성된다. 따라서 kernel development에는 C를 충분히 이해해야 한다. 특정 architecture의 low-level 개발을 할 계획이 아니라면 assembly 지식은 필수 사항이 아니다.

아래 책들은 탄탄한 C 교육이나 수년간의 경험을 대신할 수는 없지만 참고서로 유용하다.

• Kernighan과 Ritchie의 “The C Programming Language” [Prentice Hall]
• Steve Oualline의 “Practical C Programming” [O'Reilly]
• Harbison과 Steele의 “C: A Reference Manual” [Prentice Hall]

Kernel은 GNU C와 GNU toolchain을 사용한다. ISO C11 표준을 따르지만 표준에 없는 여러 GNU extension도 사용한다. Kernel은 standard C library에 의존하지 않는 freestanding C environment이므로 C 표준의 일부 기능은 지원되지 않는다. 임의의 long long division과 floating point 연산도 허용되지 않는다.

Kernel이 toolchain에 대해 두는 전제와 사용하는 extension을 모두 설명하는 결정적 참고 자료는 없다. 관련 정보는 gcc info page에서 확인할 수 있다.

info gcc

목표는 이미 존재하는 development community와 일하는 법을 배우는 것이다. 이 community는 다양한 사람으로 구성되어 있고 coding, style, procedure에 높은 기준을 둔다. 이 기준은 규모가 크고 지리적으로 흩어진 팀에서 가장 잘 작동했던 방법을 오랜 시간 축적해 만든 것이다. 기준은 잘 문서화되어 있으므로 미리 최대한 익혀야 하며, 다른 개발자들이 자신이나 자기 회사의 업무 방식에 맞춰 줄 것이라고 기대해서는 안 된다.

Introduzione
------------
Dunque, volete imparare come diventare sviluppatori del kernel Linux?
O vi è stato detto dal vostro capo, "Vai, scrivi un driver Linux per
questo dispositivo". Bene, l'obbiettivo di questo documento è quello
di insegnarvi tutto ciò che dovete sapere per raggiungere il vostro
scopo descrivendo il procedimento da seguire e consigliandovi
su come lavorare con la comunità. Il documento cercherà, inoltre,
di spiegare alcune delle ragioni per le quali la comunità lavora in un
modo suo particolare.

Il kernel è scritto prevalentemente nel linguaggio C con alcune parti
specifiche dell'architettura scritte in linguaggio assembly.
Per lo sviluppo kernel è richiesta una buona conoscenza del linguaggio C.
L'assembly (di qualsiasi architettura) non è richiesto, a meno che non
pensiate di fare dello sviluppo di basso livello per un'architettura.
Sebbene essi non siano un buon sostituto ad un solido studio del
linguaggio C o ad anni di esperienza, i seguenti libri sono, se non
altro, utili riferimenti:

- "The C Programming Language" di Kernighan e Ritchie [Prentice Hall]
- "Practical C Programming" di Steve Oualline [O'Reilly]
- "C:  A Reference Manual" di Harbison and Steele [Prentice Hall]

Il kernel è stato scritto usando GNU C e la toolchain GNU.
Sebbene si attenga allo standard ISO C11, esso utilizza una serie di
estensioni che non sono previste in questo standard. Il kernel è un
ambiente C indipendente, che non ha alcuna dipendenza dalle librerie
C standard, così alcune parti del C standard non sono supportate.
Le divisioni ``long long`` e numeri in virgola mobile non sono permessi.
Qualche volta è difficile comprendere gli assunti che il kernel ha
riguardo gli strumenti e le estensioni in uso, e sfortunatamente non
esiste alcuna indicazione definitiva. Per maggiori informazioni, controllate,
la pagina `info gcc`.

Tenete a mente che state cercando di apprendere come lavorare con la comunità
di sviluppo già esistente. Questo è un gruppo eterogeneo di persone, con alti
standard di codifica, di stile e di procedura. Questi standard sono stati
creati nel corso del tempo basandosi su quanto hanno riscontrato funzionare al
meglio per un squadra così grande e geograficamente sparsa. Cercate di
imparare, in anticipo, il più possibile circa questi standard, poichè ben
spiegati; non aspettatevi che gli altri si adattino al vostro modo di fare
o a quello della vostra azienda.

법률과 license

Linux kernel source code는 GPL에 따라 공개됩니다. License의 세부 조건은 source tree 최상위의 `COPYING` file에서 확인합니다.

License에 관해 추가 질문이 있다면 변호사에게 문의해야 하며 Linux kernel mailing list에 묻지 않아야 합니다. Mailing list 참여자는 변호사가 아니므로 법률 문제에 관한 그들의 발언에 의존해서는 안 됩니다. GPL의 일반적인 질문과 답변은 GNU GPL FAQ에서 확인할 수 있습니다.

• GNU GPL FAQhttps://www.gnu.org/licenses/gpl-faq.html

Note legali
------------
Il codice sorgente del kernel Linux è rilasciato sotto GPL. Siete pregati
di visionare il file, COPYING, presente nella cartella principale dei
sorgente, per eventuali dettagli sulla licenza. Se avete ulteriori domande
sulla licenza, contattate un avvocato, non chiedete sulle liste di discussione
del kernel Linux. Le persone presenti in queste liste non sono avvocati,
e non dovreste basarvi sulle loro dichiarazioni in materia giuridica.

Per domande più frequenti e risposte sulla licenza GPL, guardare:

	https://www.gnu.org/licenses/gpl-faq.html

먼저 읽어야 할 Documentation

Linux kernel source tree에는 kernel community와 상호 작용하는 방법을 배우는 데 유용한 문서가 폭넓게 들어 있습니다. Kernel에 새 기능을 추가할 때는 그 기능의 사용법을 설명하는 documentation file도 함께 추가하는 것이 권장됩니다.

Kernel change로 userspace interface가 바뀌면 그 변경을 설명하는 정보나 man page patch를 `alx@kernel.org`로 보내고 `linux-api@vger.kernel.org`를 CC하는 것이 권장됩니다.

Source tree의 필독 문서

• `Documentation/translations/it_IT/admin-guide/README.rst`: Linux kernel의 간략한 배경과 configuration·build에 필요한 최소 작업을 설명합니다. Kernel 입문자는 여기서 시작합니다.
• `Documentation/translations/it_IT/process/changes.rst`: Kernel을 성공적으로 compile하고 실행하는 데 필요한 software package를 나열합니다.
• `Documentation/translations/it_IT/process/coding-style.rst`: Linux kernel coding style과 그 근거를 설명합니다. 새 code는 이 지침을 따라야 하며, 많은 maintainer와 reviewer는 올바른 style의 patch만 검토합니다.
• `Documentation/translations/it_IT/process/submitting-patches.rst`: Email 내용·형식·수신자를 포함해 patch를 만들고 보내는 방법을 설명합니다. 규칙을 따른다고 성공이 보장되지는 않지만, 따르지 않으면 거의 언제나 받아들여지지 않습니다.
• `Documentation/translations/it_IT/process/stable-api-nonsense.rst`: Kernel 내부에 stable API를 두지 않는 이유와 shim layer, operating system 사이의 driver portability, 빠른 source change를 다룹니다.
• `Documentation/translations/it_IT/process/security-bugs.rst`: Security problem을 kernel developer에게 알리고 해결을 돕는 절차를 설명합니다.
• `Documentation/translations/it_IT/process/management-style.rst`: Linux kernel maintainer의 업무 방식과 공통 철학을 설명합니다.
• `Documentation/translations/it_IT/process/stable-kernel-rules.rst`: Stable kernel release의 규칙과 변경을 stable release에 넣는 절차를 설명합니다.
• `Documentation/translations/it_IT/process/kernel-docs.rst`: Kernel development와 관련된 외부 documentation 목록입니다.
• `Documentation/translations/it_IT/process/applying-patches.rst`: Patch의 의미와 여러 kernel development branch에 적용하는 방법을 소개합니다.

좋은 patch를 만드는 추가 자료로 ‘The Perfect Patch’와 보관된 ‘Linux kernel patch submission format’ 문서가 있습니다.

• The Perfect Patchhttps://www.ozlabs.org/~akpm/stuff/tpp.txt
• Linux kernel patch submission formathttps://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html

Documentation build

Kernel에는 source code나 이 문서와 같은 ReStructuredText(ReST) file에서 자동 생성할 수 있는 문서도 많습니다. 여기에는 kernel 내부 API의 전체 설명과 locking을 올바르게 다루는 규칙이 포함됩니다. Source tree 최상위에서 다음 명령으로 PDF와 HTML을 생성합니다.

make pdfdocs
make htmldocs

ReST 문서는 `Documentation/output`에 생성되며 LaTeX와 ePub 형식도 만들 수 있습니다.

make latexdocs
make epubdocs

Documentazione
--------------
I sorgenti del kernel Linux hanno una vasta base di documenti che vi
insegneranno come interagire con la comunità del kernel. Quando nuove
funzionalità vengono aggiunte al kernel, si raccomanda di aggiungere anche i
relativi file di documentatione che spiegano come usarele.
Quando un cambiamento del kernel genera anche un cambiamento nell'interfaccia
con lo spazio utente, è raccomandabile che inviate una notifica o una
correzione alle pagine *man* spiegando tale modifica agli amministratori di
queste pagine all'indirizzo alx@kernel.org, aggiungendo in CC la
lista linux-api@vger.kernel.org.

Di seguito una lista di file che sono presenti nei sorgente del kernel e che
è richiesto che voi leggiate:

  :ref:`Documentation/translations/it_IT/admin-guide/README.rst <it_readme>`
    Questo file da una piccola anteprima del kernel Linux e descrive il
    minimo necessario per configurare e generare il kernel. I novizi
    del kernel dovrebbero iniziare da qui.

  :ref:`Documentation/translations/it_IT/process/changes.rst <it_changes>`

    Questo file fornisce una lista dei pacchetti software necessari
    a compilare e far funzionare il kernel con successo.

  :ref:`Documentation/translations/it_IT/process/coding-style.rst <it_codingstyle>`

    Questo file descrive lo stile della codifica per il kernel Linux,
    e parte delle motivazioni che ne sono alla base. Tutto il nuovo codice deve
    seguire le linee guida in questo documento. Molti amministratori
    accetteranno patch solo se queste osserveranno tali regole, e molte
    persone revisioneranno il codice solo se scritto nello stile appropriato.

  :ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`

    Questo file descrive dettagliatamente come creare ed inviare una patch
    con successo, includendo (ma non solo questo):

       - Contenuto delle email
       - Formato delle email
       - I destinatari delle email

    Seguire tali regole non garantirà il successo (tutte le patch sono soggette
    a controlli realitivi a contenuto e stile), ma non seguirle lo precluderà
    sempre.

    Altre ottime descrizioni di come creare buone patch sono:

	"The Perfect Patch"
		https://www.ozlabs.org/~akpm/stuff/tpp.txt

	"Linux kernel patch submission format"
		https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html

  :ref:`Documentation/translations/it_IT/process/stable-api-nonsense.rst <it_stable_api_nonsense>`

    Questo file descrive la motivazioni sottostanti la conscia decisione di
    non avere un API stabile all'interno del kernel, incluso cose come:

      - Sottosistemi shim-layers (per compatibilità?)
      - Portabilità fra Sistemi Operativi dei driver.
      - Attenuare i rapidi cambiamenti all'interno dei sorgenti del kernel
        (o prevenirli)

    Questo documento è vitale per la comprensione della filosifia alla base
    dello sviluppo di Linux ed è molto importante per le persone che arrivano
    da esperienze con altri Sistemi Operativi.

  :ref:`Documentation/translations/it_IT/process/security-bugs.rst <it_securitybugs>`
    Se ritenete di aver trovato un problema di sicurezza nel kernel Linux,
    seguite i passaggi scritti in questo documento per notificarlo agli
    sviluppatori del kernel, ed aiutare la risoluzione del problema.

  :ref:`Documentation/translations/it_IT/process/management-style.rst <it_managementstyle>`
    Questo documento descrive come i manutentori del kernel Linux operano
    e la filosofia comune alla base del loro metodo.  Questa è un'importante
    lettura per tutti coloro che sono nuovi allo sviluppo del kernel (o per
    chi è semplicemente curioso), poiché risolve molti dei più comuni
    fraintendimenti e confusioni dovuti al particolare comportamento dei
    manutentori del kernel.

  :ref:`Documentation/translations/it_IT/process/stable-kernel-rules.rst <it_stable_kernel_rules>`
    Questo file descrive le regole sulle quali vengono basati i rilasci del
    kernel, e spiega cosa fare se si vuole che una modifica venga inserita
    in uno di questi rilasci.

  :ref:`Documentation/translations/it_IT/process/kernel-docs.rst <it_kernel_docs>`
    Una lista di documenti pertinenti allo sviluppo del kernel.
    Per favore consultate questa lista se non trovate ciò che cercate nella
    documentazione interna del kernel.

  :ref:`Documentation/translations/it_IT/process/applying-patches.rst <it_applying_patches>`
    Una buona introduzione che descrivere esattamente cos'è una patch e come
    applicarla ai differenti rami di sviluppo del kernel.

Il kernel inoltre ha un vasto numero di documenti che possono essere
automaticamente generati dal codice sorgente stesso o da file
ReStructuredText (ReST), come questo. Esso include una completa
descrizione dell'API interna del kernel, e le regole su come gestire la
sincronizzazione (locking) correttamente

Tutte queste tipologie di documenti possono essere generati in PDF o in
HTML utilizzando::

	make pdfdocs
	make htmldocs

rispettivamente dalla cartella principale dei sorgenti del kernel.

I documenti che impiegano ReST saranno generati nella cartella
Documentation/output.
Questi posso essere generati anche in formato LaTex e ePub con::

	make latexdocs
	make epubdocs

Kernel developer로 첫발을 내딛기

Linux kernel development를 전혀 모른다면 Linux KernelNewbies project를 먼저 살펴본다. 이 project에는 기본적인 kernel development 질문을 거의 무엇이든 물어볼 수 있는 mailing list가 있다. 다만 이미 답변된 질문을 다시 올리지 않도록 먼저 archive를 검색해야 한다.

KernelNewbies에는 실시간으로 질문할 수 있는 IRC channel과 Linux kernel development 학습에 도움이 되는 documentation도 많다. Website는 code organization, subsystem, tree 내부와 외부의 현재 project에 관한 기본 정보뿐 아니라 kernel compile과 patch 적용 같은 기초 절차도 설명한다.

어디서 시작할지 정하지 못했지만 kernel development community에 참여할 첫 작업을 찾고 싶다면 Linux Kernel Janitors project를 방문한다. Kernel source tree에서 정리하거나 고쳐야 할 비교적 단순한 문제 목록이 있어 좋은 출발점이 된다. Project 담당 developer와 함께 작업하면서 patch를 Linux kernel tree에 넣는 기본 절차를 배우고, 다음 작업 방향도 안내받을 수 있다.

Kernel code를 실제로 수정하기 전에 대상 code가 어떻게 동작하는지 이해하는 것은 필수다. 가장 좋은 방법은 source를 직접 읽는 것이며, 까다로운 부분 대부분에는 좋은 comment가 있다. 필요하면 전용 도구도 활용한다. 특히 권장되는 Linux Cross-Reference project는 source code를 상호 참조 가능한 indexed webpage 형태로 보여 준다. 최신 kernel source는 Elixir에서 탐색할 수 있다.

• Linux KernelNewbieshttps://kernelnewbies.org
• Linux Kernel Janitorshttps://kernelnewbies.org/KernelJanitors
• Elixir Cross Referencerhttps://elixir.bootlin.com/

Diventare uno sviluppatore del kernel
-------------------------------------
Se non sapete nulla sullo sviluppo del kernel Linux, dovreste dare uno
sguardo al progetto *Linux KernelNewbies*:

	https://kernelnewbies.org

Esso prevede un'utile lista di discussione dove potete porre più o meno ogni
tipo di quesito relativo ai concetti fondamentali sullo sviluppo del kernel
(assicuratevi di cercare negli archivi, prima di chiedere qualcosa alla
quale è già stata fornita risposta in passato). Esistono inoltre, un canale IRC
che potete usare per formulare domande in tempo reale, e molti documenti utili
che vi faciliteranno nell'apprendimento dello sviluppo del kernel Linux.

Il sito internet contiene informazioni di base circa l'organizzazione del
codice, sottosistemi e progetti attuali (sia interni che esterni a Linux).
Esso descrive, inoltre, informazioni logistiche di base, riguardanti ad esempio
la compilazione del kernel e l'applicazione di una modifica.

Se non sapete dove cominciare, ma volete cercare delle attività dalle quali
partire per partecipare alla comunità di sviluppo, andate al progetto Linux
Kernel Janitor's.

	https://kernelnewbies.org/KernelJanitors

È un buon posto da cui iniziare. Esso presenta una lista di problematiche
relativamente semplici da sistemare e pulire all'interno della sorgente del
kernel Linux. Lavorando con gli sviluppatori incaricati di questo progetto,
imparerete le basi per l'inserimento delle vostre modifiche all'interno dei
sorgenti del kernel Linux, e possibilmente, sarete indirizzati al lavoro
successivo da svolgere, se non ne avrete ancora idea.

Prima di apportare una qualsiasi modifica al codice del kernel Linux,
è imperativo comprendere come tale codice funziona. A questo scopo, non c'è
nulla di meglio che leggerlo direttamente (la maggior parte dei bit più
complessi sono ben commentati), eventualmente anche con l'aiuto di strumenti
specializzati. Uno degli strumenti che è particolarmente raccomandato è
il progetto Linux Cross-Reference, che è in grado di presentare codice
sorgente in un formato autoreferenziale ed indicizzato. Un eccellente ed
aggiornata fonte di consultazione del codice del kernel la potete trovare qui:

	https://elixir.bootlin.com/

4.x kernel development branch와 merge 흐름

이 문서가 설명하는 Linux kernel development process는 mainline 4.x source, 4.x.y stable source, subsystem별 source와 patch, 4.x-next integration testing tree로 구성됩니다.

4.x mainline source

4.x kernel은 Linus Torvalds가 관리하며 `https://kernel.org`의 `pub/linux/kernel/v4.x/`에서 찾을 수 있습니다.

• 새 kernel이 release되면 2주간의 merge window가 열립니다. Maintainer는 이 기간에 큰 변경을 Linus에게 제안하며, 보통 -next branch에서 이미 몇 주 동안 검증된 변경입니다. Git 제출이 선호되지만 일반 patch도 허용됩니다.
• 2주 뒤 -rc1이 release되면 목표는 kernel을 최대한 견고하게 만드는 것입니다. Patch 대부분은 regression을 고쳐야 합니다. 오래전부터 있던 bug는 regression이 아니므로 중요할 때만 보냅니다. 새 driver나 filesystem 전체는 self-contained이고 추가 code 밖에 영향을 주지 않으면 -rc1 뒤에도 받아들여질 수 있습니다. 이때도 public mailing list에 patch를 보내 review받아야 합니다.
• Linus가 현재 source를 test하기에 충분히 정상적이라고 판단할 때마다 새 -rc가 release되며, 목표 주기는 매주 하나입니다.
• Kernel이 준비됐다고 판단될 때까지 이 과정이 계속되며 보통 약 6주가 걸립니다.

4.x.y stable source

세 부분으로 된 version의 kernel은 stable kernel입니다. 특정 4.x kernel에서 발견된 security 문제나 중대한 regression을 고치는 비교적 작고 중요한 fix가 들어갑니다.

최신 stable kernel을 원하지만 development 또는 experimental version test에는 참여하지 않으려는 사용자에게 권장되는 branch입니다. 4.x.y kernel이 없다면 번호가 가장 높은 4.x kernel이 최신 stable입니다.

4.x.y는 stable team `<stable@vger.kernel.org>`이 관리하고 필요에 따라 release합니다. 보통 약 2주 간격이지만 긴급한 문제가 없으면 더 길어질 수 있고, security 문제가 있으면 즉시 release될 수 있습니다.

`Documentation/process/stable-kernel-rules.rst`는 stable tree에 허용되는 변경과 release 절차를 설명합니다.

Subsystem source와 patch

Kernel subsystem maintainer와 여러 developer는 현재 개발 상태를 repository로 공개합니다. 개발 속도가 빠른 영역에서는 제출물과 진행 중인 작업의 conflict를 피하도록 subsystem repository를 base로 patch를 만들라는 요청을 받을 수 있습니다.

대부분 Git repository지만 다른 SCM이나 quilt series도 사용됩니다. 주소는 `MAINTAINERS`에 기록되며 많은 repository를 `https://git.kernel.org/`에서 찾을 수 있습니다.

변경이 subsystem tree에 포함되기 전에는 mailing list에서 review됩니다. 여러 subsystem은 Patchwork로 게시된 patch, comment와 revision을 추적하고 상태를 review 중·accepted·rejected로 표시합니다.

4.x-next integration testing tree

Subsystem update를 mainline 4.x에 merge하기 전에 integration test해야 합니다. 이를 위해 거의 모든 subsystem branch를 매일 포함하는 linux-next testing repository가 운영됩니다.

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git

-next kernel은 다음 merge window에 mainline으로 들어갈 내용을 미리 보여 줍니다. 실제로 -next kernel을 실행해 test하는 참여는 매우 환영받습니다.

• Kernel.orghttps://kernel.org
• Githttps://git-scm.com/
• Kernel Githttps://git.kernel.org/
• Kernel Patchworkhttps://patchwork.kernel.org/

Il processo di sviluppo
-----------------------
Il processo di sviluppo del kernel Linux si compone di pochi "rami" principali
e di molti altri rami per specifici sottosistemi. Questi rami sono:

  - I sorgenti kernel 4.x
  - I sorgenti stabili del kernel 4.x.y -stable
  - Sorgenti dei sottosistemi del kernel e le loro modifiche
  - Il kernel 4.x -next per test d'integrazione

I sorgenti kernel 4.x
~~~~~~~~~~~~~~~~~~~~~

I kernel 4.x sono amministrati da Linus Torvald, e possono essere trovati
su https://kernel.org nella cartella pub/linux/kernel/v4.x/. Il processo
di sviluppo è il seguente:

  - Non appena un nuovo kernel viene rilasciato si apre una finestra di due
    settimane. Durante questo periodo i manutentori possono proporre a Linus
    dei grossi cambiamenti; solitamente i cambiamenti che sono già stati
    inseriti nel ramo -next del kernel per alcune settimane. Il modo migliore
    per sottoporre dei cambiamenti è attraverso git (lo strumento usato per
    gestire i sorgenti del kernel, più informazioni sul sito
    https://git-scm.com/) ma anche delle patch vanno bene.

  - Al termine delle due settimane un kernel -rc1 viene rilasciato e
    l'obbiettivo ora è quello di renderlo il più solido possibile. A questo
    punto la maggior parte delle patch dovrebbero correggere un'eventuale
    regressione. I bachi che sono sempre esistiti non sono considerabili come
    regressioni, quindi inviate questo tipo di cambiamenti solo se sono
    importanti. Notate che un intero driver (o filesystem) potrebbe essere
    accettato dopo la -rc1 poiché non esistono rischi di una possibile
    regressione con tale cambiamento, fintanto che quest'ultimo è
    auto-contenuto e non influisce su aree esterne al codice che è stato
    aggiunto. git può essere utilizzato per inviare le patch a Linus dopo che
    la -rc1 è stata rilasciata, ma è anche necessario inviare le patch ad
    una lista di discussione pubblica per un'ulteriore revisione.

  - Una nuova -rc viene rilasciata ogni volta che Linus reputa che gli attuali
    sorgenti siano in uno stato di salute ragionevolmente adeguato ai test.
    L'obiettivo è quello di rilasciare una nuova -rc ogni settimana.

  - Il processo continua fino a che il kernel è considerato "pronto"; tale
    processo dovrebbe durare circa in 6 settimane.

È utile menzionare quanto scritto da Andrew Morton sulla lista di discussione
kernel-linux in merito ai rilasci del kernel:

	*"Nessuno sa quando un kernel verrà rilasciato, poichè questo è
	legato allo stato dei bachi e non ad una cronologia preventiva."*

I sorgenti stabili del kernel 4.x.y -stable
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I kernel con versioni in 3-parti sono "kernel stabili". Essi contengono
correzioni critiche relativamente piccole nell'ambito della sicurezza
oppure significative regressioni scoperte in un dato 4.x kernel.

Questo è il ramo raccomandato per gli utenti che vogliono un kernel recente
e stabile e non sono interessati a dare il proprio contributo alla verifica
delle versioni di sviluppo o sperimentali.

Se non è disponibile alcun kernel 4.x.y., quello più aggiornato e stabile
sarà il kernel 4.x con la numerazione più alta.

4.x.y sono amministrati dal gruppo "stable" <stable@vger.kernel.org>, e sono
rilasciati a seconda delle esigenze. Il normale periodo di rilascio è
approssimativamente di due settimane, ma può essere più lungo se non si
verificano problematiche urgenti. Un problema relativo alla sicurezza, invece,
può determinare un rilascio immediato.

Il file Documentation/process/stable-kernel-rules.rst (nei sorgenti) documenta
quali tipologie di modifiche sono accettate per i sorgenti -stable, e come
avviene il processo di rilascio.


Sorgenti dei sottosistemi del kernel e le loro patch
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I manutentori dei diversi sottosistemi del kernel --- ed anche molti
sviluppatori di sottosistemi --- mostrano il loro attuale stato di sviluppo
nei loro repositori. In questo modo, altri possono vedere cosa succede nelle
diverse parti del kernel. In aree dove lo sviluppo è rapido, potrebbe essere
chiesto ad uno sviluppatore di basare le proprie modifiche su questi repositori
in modo da evitare i conflitti fra le sottomissioni ed altri lavori in corso

La maggior parte di questi repositori sono git, ma esistono anche altri SCM
in uso, o file di patch pubblicate come una serie quilt.
Gli indirizzi dei repositori di sottosistema sono indicati nel file
MAINTAINERS.  Molti di questi posso essere trovati su  https://git.kernel.org/.

Prima che una modifica venga inclusa in questi sottosistemi, sarà soggetta ad
una revisione che inizialmente avviene tramite liste di discussione (vedere la
sezione dedicata qui sotto). Per molti sottosistemi del kernel, tale processo
di revisione è monitorato con lo strumento patchwork.
Patchwork offre un'interfaccia web che mostra le patch pubblicate, inclusi i
commenti o le revisioni fatte, e gli amministratori possono indicare le patch
come "in revisione", "accettate", o "rifiutate". Diversi siti Patchwork sono
elencati al sito https://patchwork.kernel.org/.

Il kernel 4.x -next per test d'integrazione
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Prima che gli aggiornamenti dei sottosistemi siano accorpati nel ramo
principale 4.x, sarà necessario un test d'integrazione.
A tale scopo, esiste un repositorio speciale di test nel quale virtualmente
tutti i rami dei sottosistemi vengono inclusi su base quotidiana:

	https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git

In questo modo, i kernel -next offrono uno sguardo riassuntivo su quello che
ci si aspetterà essere nel kernel principale nel successivo periodo
d'incorporazione.
Coloro che vorranno fare dei test d'esecuzione del kernel -next sono più che
benvenuti.

Bug report 작성과 관리

Main kernel source directory의 Documentation/admin-guide/reporting-issues.rst는 의심되는 kernel bug를 보고하는 방법과 developer가 문제를 추적하는 데 필요한 정보의 종류를 설명한다.

다른 사람이 보고한 bug를 고치는 일은 kernel hacking 기술을 실제로 적용하는 가장 좋은 방법 중 하나다. Kernel을 더 안정적으로 만들 뿐 아니라 현실의 문제를 해결하는 법을 배우고 실력이 늘며, 다른 developer에게 자신의 존재도 알릴 수 있다. 다른 사람의 bug를 고치는 데 시간을 쓰고 싶어 하는 사람이 많지 않기 때문에 이 작업은 developer 사이에서 신뢰를 얻는 좋은 방법이기도 하다.

기존 bug report를 다루려면 관심 있는 subsystem을 고른다. MAINTAINERS file에서 그 subsystem의 bug가 어디로 보고되는지 확인한다. 보통 mailing list이고 드물게 bug tracker다. 해당 장소의 archive에서 최근 report를 검색하고 도울 수 있는 문제에 참여한다.

bugzilla.kernel.org도 확인할 수 있다. 이를 적극적으로 report 또는 tracking에 사용하는 subsystem은 소수지만 kernel 전체에 관한 bug가 이곳에 등록되기도 한다.

• Linux Kernel Bugzillahttps://bugzilla.kernel.org

Riportare Bug
-------------

Il file 'Documentation/admin-guide/reporting-issues.rst' nella
cartella principale del kernel spiega come segnalare un baco nel
kernel, e fornisce dettagli su quali informazioni sono necessarie agli
sviluppatori del kernel per poter studiare il problema.

Gestire i rapporti sui bug
--------------------------

Uno dei modi migliori per mettere in pratica le vostre capacità di hacking è
quello di riparare bachi riportati da altre persone. Non solo aiuterete a far
diventare il kernel più stabile, ma imparerete a riparare problemi veri dal
mondo ed accrescerete le vostre competenze, e gli altri sviluppatori saranno
al corrente della vostra presenza. Riparare bachi è una delle migliori vie per
acquisire meriti tra gli altri sviluppatori, perchè non a molte persone piace
perdere tempo a sistemare i bachi di altri.

Per lavorare sui bachi già segnalati, per prima cosa cercate il
sottosistema che vi interessa. Poi, verificate nel file MAINTAINERS
dove vengono collezionati solitamente i bachi per quel sottosistema;
spesso sarà una lista di discussione, raramente un bugtracker. Cercate
bachi nell'archivio e aiutate dove credete di poterlo fare. Potete
anche consultare https://bugzilla.kernel.org; però, solo una manciata di
sottosistemi lo usano attivamente, ciò nonostante i bachi che
coinvolgono l'intero kernel sono sempre riportati lì.

Mailing list 사용법

핵심 kernel developer 대부분은 Linux Kernel Mailing List에 참여한다. 구독과 구독 해제 방법은 subspace.kernel.org의 안내에서 확인할 수 있다. Mailing list archive는 여러 web site에 있으며 search engine으로 찾을 수 있다. 대표적인 archive는 lore.kernel.org/linux-kernel이다.

List에 주제를 올리기 전에 관련 archive를 검색하는 것이 매우 권장된다. 이미 자세히 논의됐지만 mailing list archive에만 기록된 내용이 많다. Kernel subsystem 대부분은 별도의 development mailing list를 가지며 각 list는 MAINTAINERS file에서 확인할 수 있다. 여러 list가 kernel.org에 hosting되고 그 정보는 subspace.kernel.org에 있다.

Mailing list에서는 올바른 대화 습관을 지켜야 한다. 여러 사람이 답장하면 CC 수신자 목록이 상당히 길어질 수 있다. 정당한 이유 없이 CC에서 사람을 빼거나 list 주소에만 답장하지 않는다. 보낸 사람에게서 온 mail과 list를 거친 mail을 두 번 받는 것에 익숙해져야 하며, 복잡한 mail header를 추가해 이를 조정하려 하면 다른 참여자가 좋아하지 않는다.

답장의 문맥과 인용 주체를 그대로 유지한다. 답장 위쪽의 “John Kernelhacker wrote ...:” 같은 line을 남겨 두고, mail 맨 위에 답을 몰아 쓰지 말고 인용한 개별 구간 사이에 자신의 설명을 적는다.

Mail에 patch를 넣을 때는 Documentation/process/submitting-patches.rst가 요구하는 읽을 수 있는 plain text로 보낸다. Kernel developer는 attachment나 compressed patch를 다루고 싶어 하지 않는다. Patch의 개별 line에 comment하려면 plain text가 필요하다.

Space와 tab 문자를 훼손하지 않는 mail program을 사용해야 한다. 좋은 첫 test는 자신에게 mail을 보낸 뒤 그 mail의 patch를 직접 적용해 보는 것이다. 적용되지 않으면 제대로 될 때까지 mail program 설정을 고치거나 program을 바꾼다. 무엇보다 다른 subscriber를 존중해야 한다.

• Kernel mailing list subscriptionhttps://subspace.kernel.org/subscribing.html
• Linux-kernel archivehttps://lore.kernel.org/linux-kernel/
• Kernel mailing listshttps://subspace.kernel.org
• Mailing list etiquettehttps://subspace.kernel.org/etiquette.html

Liste di discussione
--------------------

Come descritto in molti dei documenti qui sopra, la maggior parte degli
sviluppatori del kernel partecipano alla lista di discussione Linux Kernel.
I dettagli su come iscriversi e disiscriversi dalla lista possono essere
trovati al sito:

	https://subspace.kernel.org/subscribing.html

Ci sono diversi archivi della lista di discussione. Usate un qualsiasi motore
di ricerca per trovarli. Per esempio:

	https://lore.kernel.org/linux-kernel/

É caldamente consigliata una ricerca in questi archivi sul tema che volete
sollevare, prima di pubblicarlo sulla lista. Molte cose sono già state
discusse in dettaglio e registrate negli archivi della lista di discussione.

Molti dei sottosistemi del kernel hanno anche una loro lista di discussione
dedicata.  Guardate nel file MAINTAINERS per avere una lista delle liste di
discussione e il loro uso.

Molte di queste liste sono gestite su kernel.org. Per informazioni consultate
la seguente pagina:

	https://subspace.kernel.org

Per favore ricordatevi della buona educazione quando utilizzate queste liste.
Sebbene sia un pò dozzinale, il seguente URL contiene alcune semplici linee
guida per interagire con la lista (o con qualsiasi altra lista):

	https://subspace.kernel.org/etiquette.html

Se diverse persone rispondo alla vostra mail, la lista dei riceventi (copia
conoscenza) potrebbe diventare abbastanza lunga. Non cancellate nessuno dalla
lista di CC: senza un buon motivo, e non rispondete solo all'indirizzo
della lista di discussione. Fateci l'abitudine perché capita spesso di
ricevere la stessa email due volte: una dal mittente ed una dalla lista; e non
cercate di modificarla aggiungendo intestazioni stravaganti, agli altri non
piacerà.

Ricordate di rimanere sempre in argomento e di mantenere le attribuzioni
delle vostre risposte invariate; mantenete il "John Kernelhacker wrote ...:"
in cima alla vostra replica e aggiungete le vostre risposte fra i singoli
blocchi citati, non scrivete all'inizio dell'email.

Se aggiungete patch alla vostra mail, assicuratevi che siano del tutto
leggibili come indicato in Documentation/process/submitting-patches.rst.
Gli sviluppatori kernel non vogliono avere a che fare con allegati o patch
compresse; vogliono invece poter commentare le righe dei vostri cambiamenti,
il che può funzionare solo in questo modo.
Assicuratevi di utilizzare un gestore di mail che non alterì gli spazi ed i
caratteri. Un ottimo primo test è quello di inviare a voi stessi una mail e
cercare di sottoporre la vostra stessa patch. Se non funziona, sistemate il
vostro programma di posta, o cambiatelo, finché non funziona.

Ed infine, per favore ricordatevi di mostrare rispetto per gli altri
sottoscriventi.

Community review와 대응

Kernel community의 목표는 가능한 한 최고의 kernel을 만드는 것이다. 받아들여 달라고 제출한 patch는 기술적 가치만을 기준으로 review된다. 제출자는 criticism, comment, 변경 요청, 근거 설명 요청 또는 아무 답도 없는 silence를 예상해야 한다.

이는 patch를 kernel에 넣는 과정의 일부다. Patch에 대한 비판과 comment를 받아들이고 기술적 관점에서 평가한 뒤 patch를 다시 고치거나, 요청된 변경을 하지 않아야 하는 이유를 명확하고 간결하게 설명할 수 있어야 한다.

게시물에 답이 없으면 며칠 기다렸다가 다시 시도한다. 엄청난 mail 양 때문에 누락되는 경우가 있다. 반대로 patch가 아무 질문 없이 받아들여질 것이라고 기대하거나, 방어적으로 반응하거나, comment를 무시하거나, 요청된 변경을 하나도 반영하지 않은 채 같은 patch를 다시 제출해서는 안 된다.

최선의 기술적 해법을 찾는 community에서는 patch가 얼마나 유익한지를 두고 언제나 다른 의견이 나올 수 있다. 협력적인 태도를 유지하고 자신의 idea가 kernel에 맞도록 조정할 의지가 있어야 하며, 최소한 그 idea가 가치 있음을 입증할 준비가 되어 있어야 한다. 틀리는 것 자체는 괜찮다. 올바른 해법을 향해 함께 일하려는 자세가 중요하다.

첫 patch에 대한 답장이 고쳐야 할 사항 열두 개를 나열하는 것뿐이어도 정상이다. 이는 patch가 받아들여지지 않는다는 뜻도 아니고 개인을 공격하려는 뜻도 아니다. 지적된 문제를 모두 고친 뒤 patch를 다시 보내면 된다.

Lavorare con la comunità
------------------------

L'obiettivo di questa comunità è quello di fornire il miglior kernel possibile.
Quando inviate una modifica che volete integrare, sarà valutata esclusivamente
dal punto di vista tecnico. Quindi, cosa dovreste aspettarvi?

  - critiche
  - commenti
  - richieste di cambiamento
  - richieste di spiegazioni
  - nulla

Ricordatevi che questo fa parte dell'integrazione della vostra modifica
all'interno del kernel.  Dovete essere in grado di accettare le critiche,
valutarle a livello tecnico ed eventualmente rielaborare nuovamente le vostre
modifiche o fornire delle chiare e concise motivazioni per le quali le
modifiche suggerite non dovrebbero essere fatte.
Se non riceverete risposte, aspettate qualche giorno e riprovate ancora,
qualche volta le cose si perdono nell'enorme mucchio di email.

Cosa non dovreste fare?

  - aspettarvi che la vostra modifica venga accettata senza problemi
  - mettervi sulla difensiva
  - ignorare i commenti
  - sottomettere nuovamente la modifica senza fare nessuno dei cambiamenti
    richiesti

In una comunità che è alla ricerca delle migliori soluzioni tecniche possibili,
ci saranno sempre opinioni differenti sull'utilità di una modifica.
Siate cooperativi e vogliate adattare la vostra idea in modo che sia inserita
nel kernel.  O almeno vogliate dimostrare che la vostra idea vale.
Ricordatevi, sbagliare è accettato fintanto che siate disposti a lavorare verso
una soluzione che è corretta.

È normale che le risposte alla vostra prima modifica possa essere
semplicemente una lista con dozzine di cose che dovreste correggere.
Questo **non** implica che la vostra patch non sarà accettata, e questo
**non** è contro di voi personalmente.
Semplicemente correggete tutte le questioni sollevate contro la vostra modifica
ed inviatela nuovamente.

Kernel community와 기업 조직의 차이

Kernel community는 전통적인 기업 개발 환경 대부분과 다르게 움직인다. 제안하는 변경을 설명할 때 좋은 표현은 여러 문제를 해결한다는 점, code 2,000줄을 삭제한다는 점, 설명하려는 내용을 보여 주는 patch가 있다는 점, 서로 다른 architecture 5개에서 test했다는 점, 작은 patch의 series라는 점, 일반적인 machine에서 performance를 높인다는 점처럼 기술적 결과와 검증 가능성을 드러낸다.

반대로 “AIX/ptx/Solaris에서 이렇게 했으니 좋은 방식이다”, “이 일을 20년 했다”, “우리 회사가 돈을 벌려면 필요하다”, “Enterprise product line을 위한 것이다”, “idea를 설명하는 1,000 page design document가 있다”, “6개월 동안 작업했다”, “5,000 line patch다”, “현재의 엉망인 부분을 전부 다시 작성했다”, “deadline 때문에 지금 적용해야 한다” 같은 말은 피해야 한다. 경력, 조직 사정, 투입 시간이나 큰 문서보다 code와 기술적 근거가 판단 기준이다.

Kernel community의 또 다른 차이는 서로 얼굴을 보지 않는 상호 작용이다. 문서는 email과 IRC가 주된 communication 방식이어서 성별이나 인종에 따른 차별이 줄어드는 이점이 있다고 설명한다. 참여자는 email address로 보이고, 국제적인 환경에서는 이름만으로 성별을 추측하기도 어렵다. Linux kernel에서 일한 뒤 의견을 밝힌 여성 대부분은 긍정적인 경험을 했다고 문서는 기록한다.

영어가 편하지 않은 사람에게는 language barrier가 문제가 될 수 있다. Mailing list에서 idea를 정확히 전달하려면 영어를 잘 이해해야 할 수 있으므로, 보내기 전에 email의 영어 문장이 의미가 통하는지 확인하는 것이 권장된다.

Differenze tra la comunità del kernel e le strutture aziendali
--------------------------------------------------------------

La comunità del kernel funziona diversamente rispetto a molti ambienti di
sviluppo aziendali.  Qui di seguito una lista di cose che potete provare a
fare per evitare problemi:

  Cose da dire riguardanti le modifiche da voi proposte:

  - "Questo risolve più problematiche."
  - "Questo elimina 2000 stringhe di codice."
  - "Qui una modifica che spiega cosa sto cercando di fare."
  - "L'ho testato su 5 diverse architetture.."
  - "Qui una serie di piccole modifiche che.."
  - "Questo aumenta le prestazioni di macchine standard..."

 Cose che dovreste evitare di dire:

    - "Lo abbiamo fatto in questo modo in AIX/ptx/Solaris, di conseguenza
       deve per forza essere giusto..."
    - "Ho fatto questo per 20 anni, quindi.."
    - "Questo è richiesto dalla mia Azienda per far soldi"
    - "Questo è per la linea di prodotti della nostra Azienda"
    - "Ecco il mio documento di design di 1000 pagine che descrive ciò che ho
       in mente"
    - "Ci ho lavorato per 6 mesi..."
    - "Ecco una patch da 5000 righe che.."
    - "Ho riscritto il pasticcio attuale, ed ecco qua.."
    - "Ho una scadenza, e questa modifica ha bisogno di essere approvata ora"

Un'altra cosa nella quale la comunità del kernel si differenzia dai più
classici ambienti di ingegneria del software è la natura "senza volto" delle
interazioni umane. Uno dei benefici dell'uso delle email e di irc come forma
primordiale di comunicazione è l'assenza di discriminazione basata su genere e
razza. L'ambienti di lavoro Linux accetta donne e minoranze perchè tutto quello
che sei è un indirizzo email.  Aiuta anche l'aspetto internazionale nel
livellare il terreno di gioco perchè non è possibile indovinare il genere
basandosi sul nome di una persona. Un uomo può chiamarsi Andrea ed una donna
potrebbe chiamarsi Pat. Gran parte delle donne che hanno lavorato al kernel
Linux e che hanno espresso una personale opinione hanno avuto esperienze
positive.

La lingua potrebbe essere un ostacolo per quelle persone che non si trovano
a loro agio con l'inglese.  Una buona padronanza del linguaggio può essere
necessaria per esporre le proprie idee in maniera appropiata all'interno
delle liste di discussione, quindi è consigliabile che rileggiate le vostre
email prima di inviarle in modo da essere certi che abbiano senso in inglese.

변경을 작은 patch로 나누기

Linux kernel community는 큰 code 덩어리를 한 번에 던져 넣는 방식을 반기지 않는다. 변경을 제대로 소개하고 논의하며 작고 독립적인 부분으로 나눠야 한다. 이는 기업에서 흔히 쓰는 방식과 거의 정반대다.

제안은 development process의 매우 이른 시점에 소개해야 작업 방향에 관한 feedback을 받을 수 있다. Community도 기능을 내다 버리듯 넘기는 것이 아니라 자신들과 함께 개발한다고 느낄 수 있다. 그렇다고 mailing list에 한 번에 email 50개를 보내서는 안 되며, 거의 언제나 patch series는 그보다 작아야 한다.

첫 번째 분할 이유는 작은 patch일수록 정확성을 검증하는 데 시간과 노력이 적게 들어 적용될 가능성이 커지기 때문이다. 5 line patch는 maintainer가 거의 한 번만 보고 적용할 수 있지만 500 line patch의 정확성을 review하는 데는 몇 시간이 걸릴 수 있다. Review 시간은 patch 크기에 지수적으로 비례한다고 표현할 정도다.

작은 patch는 문제가 생겼을 때 debug하기도 쉽다. 적용한 뒤 무언가를 깨뜨린 거대한 patch를 해부하는 것보다 patch를 하나씩 되돌리는 편이 훨씬 쉽다.

두 번째로, patch를 작게 보낼 뿐 아니라 제출 전에 다시 작성하고 단순화하거나 순서를 재배치하는 작업도 중요하다.

우아한 해법을 제시하는 일과 unfinished work를 community와 함께 논의하는 일 사이에서 균형을 잡기는 어렵다. 따라서 이른 시점에 feedback을 받아 작업을 개선하되, 전체 과제가 아직 merge할 상태가 아니더라도 완성된 작은 변경은 먼저 받아들여질 수 있도록 나눈다.

아직 완성되지 않았고 나중에 고치겠다는 patch를 inclusion 대상으로 보내는 것은 허용되지 않는다.

Spezzare le vostre modifiche
----------------------------

La comunità del kernel Linux non accetta con piacere grossi pezzi di codice
buttati lì tutti in una volta. Le modifiche necessitano di essere
adeguatamente presentate, discusse, e suddivise in parti più piccole ed
indipendenti.  Questo è praticamente l'esatto opposto di quello che le
aziende fanno solitamente.  La vostra proposta dovrebbe, inoltre, essere
presentata prestissimo nel processo di sviluppo, così che possiate ricevere
un riscontro su quello che state facendo. Lasciate che la comunità
senta che state lavorando con loro, e che non li stiate sfruttando come
discarica per le vostre aggiunte.  In ogni caso, non inviate 50 email nello
stesso momento in una lista di discussione, il più delle volte la vostra serie
di modifiche dovrebbe essere più piccola.

I motivi per i quali dovreste frammentare le cose sono i seguenti:

1) Piccole modifiche aumentano le probabilità che vengano accettate,
   altrimenti richiederebbe troppo tempo o sforzo nel verificarne
   la correttezza.  Una modifica di 5 righe può essere accettata da un
   manutentore con a mala pena una seconda occhiata. Invece, una modifica da
   500 linee può richiedere ore di rilettura per verificarne la correttezza
   (il tempo necessario è esponenzialmente proporzionale alla dimensione della
   modifica, o giù di lì)

   Piccole modifiche sono inoltre molto facili da debuggare quando qualcosa
   non va. È molto più facile annullare le modifiche una per una che
   dissezionare una patch molto grande dopo la sua sottomissione (e rompere
   qualcosa).

2) È importante non solo inviare piccole modifiche, ma anche riscriverle e
   semplificarle (o più semplicemente ordinarle) prima di sottoporle.

Qui un'analogia dello sviluppatore kernel Al Viro:

	*"Pensate ad un insegnante di matematica che corregge il compito
	di uno studente (di matematica). L'insegnante non vuole vedere le
	prove e gli errori commessi dallo studente prima che arrivi alla
	soluzione. Vuole vedere la risposta più pulita ed elegante
	possibile.  Un buono studente lo sa, e non presenterebbe mai le
	proprie bozze prima prima della soluzione finale"*

	*"Lo stesso vale per lo sviluppo del kernel. I manutentori ed i
	revisori non vogliono vedere il procedimento che sta dietro al
	problema che uno sta risolvendo. Vogliono vedere una soluzione
	semplice ed elegante."*

Può essere una vera sfida il saper mantenere l'equilibrio fra una presentazione
elegante della vostra soluzione, lavorare insieme ad una comunità e dibattere
su un lavoro incompleto.  Pertanto è bene entrare presto nel processo di
revisione per migliorare il vostro lavoro, ma anche per riuscire a tenere le
vostre modifiche in pezzettini che potrebbero essere già accettate, nonostante
la vostra intera attività non lo sia ancora.

In fine, rendetevi conto che non è accettabile inviare delle modifiche
incomplete con la promessa che saranno "sistemate dopo".

변경이 필요한 이유를 입증하기

Patch를 나누는 것과 함께 Linux community가 이 변경을 추가해야 하는 이유를 알리는 일도 매우 중요하다. 새 기능은 필요하고 유용하다는 근거를 제시해야 한다.

Giustificare le vostre modifiche
--------------------------------

Insieme alla frammentazione delle vostre modifiche, è altrettanto importante
permettere alla comunità Linux di capire perché dovrebbero accettarle.
Nuove funzionalità devono essere motivate come necessarie ed utili.

변경 내용을 기록하기

Patch를 보낼 때 email 본문에 무엇을 쓰는지 특별히 주의해야 한다. 이 정보는 patch의 ChangeLog가 되어 모든 사람이 영구히 볼 수 있도록 보존된다. Patch를 완전하게 설명해야 하며 변경이 필요한 이유, patch의 전체 design approach, implementation detail, testing result를 포함해야 한다.

정확한 형식에 관한 자세한 내용은 “The Perfect Patch”의 ChangeLog section을 참고한다.

• The Perfect Patchhttps://www.ozlabs.org/~akpm/stuff/tpp.txt

이 모든 일을 잘하기는 때때로 매우 어렵다. 이런 practice를 완성하는 데는 여러 해가 걸릴 수 있고 끝내 완벽해지지 않을 수도 있다. 많은 인내와 결단이 필요한 지속적인 개선 과정이다. 그러나 포기할 필요는 없다. 앞선 많은 사람도 해냈고 모두 지금의 입문자와 정확히 같은 자리에서 시작했다.

Documentare le vostre modifiche
-------------------------------

Quando inviate le vostre modifiche, fate particolare attenzione a quello che
scrivete nella vostra email.  Questa diventerà il *ChangeLog* per la modifica,
e sarà visibile a tutti per sempre.  Dovrebbe descrivere la modifica nella sua
interezza, contenendo:

 - perchè la modifica è necessaria
 - l'approccio d'insieme alla patch
 - dettagli supplementari
 - risultati dei test

Per maggiori dettagli su come tutto ciò dovrebbe apparire, riferitevi alla
sezione ChangeLog del documento:

 "The Perfect Patch"
      http://www.ozlabs.org/~akpm/stuff/tpp.txt

A volte tutto questo è difficile da realizzare. Il perfezionamento di queste
pratiche può richiedere anni (eventualmente). È un processo continuo di
miglioramento che richiede molta pazienza e determinazione. Ma non mollate,
si può fare. Molti lo hanno fatto prima, ed ognuno ha dovuto iniziare dove
siete voi ora.

감사의 말과 maintainer

Paolo Ciarrocchi는 자신이 작성한 글을 바탕으로 “Development Process” section을 구성하도록 허락했다. Randy Dunlap과 Gerrit Huizenga는 말해야 할 것과 말하지 않아야 할 것의 목록 일부에 기여했다.

Pat Mochel, Hanna Linder, Randy Dunlap, Kay Sievers, Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook, Andrew Morton, Andi Kleen, Vadim Lobanov, Jesper Juhl, Adrian Bunk, Keri Harris, Frans Pop, David A. Wheeler, Junio Hamano, Michael Kerrisk, Alex Shepard에게 review, comment, contribution에 대해 감사를 전한다. 이들의 도움이 없었다면 문서는 만들어질 수 없었다.

• Development Process 원문https://lwn.net/Articles/94386/

Maintainer: Greg Kroah-Hartman <greg@kroah.com>

----------

Grazie a Paolo Ciarrocchi che ha permesso che la sezione "Development Process"
(https://lwn.net/Articles/94386/) fosse basata sui testi da lui scritti, ed a
Randy Dunlap e Gerrit Huizenga per la lista di cose che dovreste e non
dovreste dire. Grazie anche a Pat Mochel, Hanna Linder, Randy Dunlap,
Kay Sievers, Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook, Andrew Morton,
Andi Kleen, Vadim Lobanov, Jesper Juhl, Adrian Bunk, Keri Harris, Frans Pop,
David A. Wheeler, Junio Hamano, Michael Kerrisk, e Alex Shepard per le
loro revisioni, commenti e contributi.  Senza il loro aiuto, questo documento
non sarebbe stato possibile.

Manutentore: Greg Kroah-Hartman <greg@kroah.com>