커널 개발 절차의 동작 방식

release cycle, merge window와 stable update

1990년대 초 Linux kernel 개발은 사용자와 개발자 수가 적어 비교적 느슨하게 진행되었다. 이후 사용자 기반이 수백만 명으로 늘고 1년 동안 참여하는 개발자도 약 2,000명에 이르면서, 개발을 원활하게 유지하기 위한 여러 절차가 생겼다. 이 community에서 효과적으로 일하려면 절차가 어떻게 동작하는지 확실히 이해해야 한다.

Kernel 개발자는 대략적인 시간 기반 release 절차를 사용하며 두세 달마다 새 major kernel을 release한다. 원문이 제시한 당시 release 이력은 다음과 같다.

각 5.x release는 새 기능과 internal API 변경 등을 포함하는 major kernel release다. 일반적인 release 하나에는 약 13,000 changeset과 수십만 line의 변경이 들어갈 수 있다. 5.x는 Linux kernel 개발의 최전선이며 major change를 계속 통합하는 rolling development model을 사용한다.

각 cycle 시작에는 merge window가 열린다. 충분히 안정적이라고 판단되고 development community가 받아들인 code가 이때 mainline에 merge된다. 새 cycle 변경의 대부분과 모든 major change가 이 기간에 들어오며 하루 약 1,000 patch 또는 changeset에 가까운 속도로 merge될 수 있다.

Merge window에 들어오는 변경은 갑자기 생긴 것이 아니다. 이미 그 전에 수집·test·staging된 code이며 뒤 절에서 이 준비 과정을 설명한다.

Merge window는 약 2주 동안 열린다. 끝나면 Linus Torvalds가 window 종료를 선언하고 첫 rc kernel을 release한다. 최종 5.6이 될 cycle이라면 첫 release는 5.6-rc1이다. -rc1은 새 feature를 merge할 시간이 끝나고 다음 kernel을 안정화할 시간이 시작됐다는 신호다.

그 다음 6~10주에는 문제를 고치는 patch만 mainline에 제출해야 한다. 더 큰 변경이 허용되는 경우도 드물게 있지만 merge window 밖에서 새 feature를 넣으려 하면 좋지 않은 반응을 받는다. Feature가 window를 놓쳤다면 일반적으로 다음 cycle을 기다려야 한다. In-tree code를 건드리지 않는 완전히 새로운 hardware driver는 regression을 만들 수 없어 예외적으로 언제든 추가될 수 있다.

Fix가 mainline에 들어오면서 patch rate는 점차 낮아진다. Linus는 약 일주일마다 새 -rc를 release하며 보통 -rc6에서 -rc9 사이에 충분히 안정적이라고 판단해 final release를 만든다. 그 시점부터 전체 절차가 다시 시작된다.

원문은 2019년의 5.4 development cycle을 다음과 같이 예로 든다.

Development cycle을 닫고 stable release를 만들 시점을 결정할 때 가장 중요한 지표는 이전 release에 비해 생긴 regression 목록이다. 어떤 bug도 바람직하지 않지만 과거에 동작하던 system을 깨뜨리는 bug는 특히 심각하다. 따라서 regression을 만든 patch는 좋지 않게 평가되며 stabilization 기간에 revert될 가능성이 높다.

목표는 stable release 전에 알려진 regression을 모두 고치는 것이다. 그러나 이 규모의 project에는 변수가 너무 많아 현실에서 완벽히 달성하기 어렵다. Final release를 계속 늦추면 다음 merge window를 기다리는 변경이 쌓이고 다음 cycle에 더 많은 regression이 생길 수 있다. 그래서 대부분 5.x kernel은 심각한 것은 아니길 바라면서도 소수의 알려진 regression을 가진 채 release된다.

Stable release가 만들어지면 이후 maintenance는 원문 작성 당시 Greg Kroah-Hartman과 Sasha Levin으로 구성된 stable team에 넘겨진다. Stable team은 5.x.y numbering으로 update를 release한다.

Update release 후보 patch는 두 조건을 충족해야 한다. 첫째, 중요한 bug를 고쳐야 한다. 둘째, 다음 development kernel을 위한 mainline에 이미 merge되어 있어야 한다. 일반 kernel은 initial release 뒤 한 development cycle보다 조금 긴 기간 동안 stable update를 받는다.

일부 kernel은 long term kernel로 지정되어 더 오래 지원된다. Long-term support 대상 선정은 특정 release를 유지할 필요와 시간이 있는 maintainer가 존재하는지에 달려 있다. 특정 future release가 반드시 long-term이 된다는 사전 계획은 없다.

• Active long-term kernel과 maintainerhttps://www.kernel.org/category/releases.html

커널은 대략 두세 달마다 새 major release를 만들며 cycle 첫 약 2주가 merge window입니다. 이때 이미 subsystem tree에서 준비·검증된 새 기능이 mainline에 들어가고, `-rc1` 뒤에는 regression과 bug 수정에 집중합니다.

보통 주 단위 `-rc`를 거쳐 안정판을 내며 이전 release에서 잘 동작하던 기능을 깨뜨린 regression을 가장 심각하게 다룹니다. 안정판 이후의 `x.y.z` update는 중요한 수정이면서 mainline에도 먼저 반영된 patch를 대상으로 합니다.

일부 release는 장기 지원 대상으로 선택되지만 미리 고정된 version 계획보다 해당 kernel을 유지할 필요와 maintainer의 시간에 따라 결정됩니다. 새 기능은 merge window를 놓치면 다음 cycle을 기다리는 것이 원칙입니다.

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

:Original: :ref:`Documentation/process/2.Process.rst <development_process>`
:Translator: Alessia Mantegazza <[email protected]>

.. _it_development_process:

Come funziona il processo di sviluppo
=====================================

Lo sviluppo del Kernel agli inizi degli anno '90 era abbastanza libero, con
un numero di utenti e sviluppatori relativamente basso.  Con una base
di milioni di utenti e con 2000 sviluppatori coinvolti nel giro di un anno,
il kernel da allora ha messo in atto un certo numero di procedure per rendere
lo sviluppo più agevole.  È richiesta una solida conoscenza di come tale
processo si svolge per poter esserne parte attiva.

Il quadro d'insieme
-------------------

Gli sviluppatori kernel utilizzano un calendario di rilascio generico, dove
ogni due o tre mesi viene effettuata un rilascio importante del kernel.
I rilasci più recenti sono stati:

	======  =================
	5.0     3 marzo, 2019
	5.1     5 maggio, 2019
	5.2     7 luglio, 2019
	5.3     15 settembre, 2019
	5.4     24 novembre, 2019
	5.5     6 gennaio, 2020
	======  =================

Ciascun rilascio 5.x è un importante rilascio del kernel con nuove
funzionalità, modifiche interne dell'API, e molto altro.  Un tipico
rilascio contiene quasi 13,000 gruppi di modifiche con ulteriori
modifiche a parecchie migliaia di linee di codice.  La 5.x. è pertanto la
linea di confine nello sviluppo del kernel Linux; il kernel utilizza un sistema
di sviluppo continuo che integra costantemente nuove importanti modifiche.

Viene seguita una disciplina abbastanza lineare per l'inclusione delle
patch di ogni rilascio. All'inizio di ogni ciclo di sviluppo, la
"finestra di inclusione" viene dichiarata aperta.  In quel momento il codice
ritenuto sufficientemente stabile(e che è accettato dalla comunità di sviluppo)
viene incluso nel ramo principale del kernel.  La maggior parte delle
patch per un nuovo ciclo di sviluppo (e tutte le più importanti modifiche)
saranno inserite durante questo periodo, ad un ritmo che si attesta sulle
1000 modifiche ("patch" o "gruppo di modifiche") al giorno.

(per inciso, vale la pena notare che i cambiamenti integrati durante la
"finestra di inclusione" non escono dal nulla; questi infatti, sono stati
raccolti e, verificati in anticipo.  Il funzionamento di tale procedimento
verrà descritto dettagliatamente più avanti).

La finestra di inclusione resta attiva approssimativamente per due settimane.
Al termine di questo periodo, Linus Torvald dichiarerà che la finestra è
chiusa e rilascerà il primo degli "rc" del kernel.
Per il kernel che è destinato ad essere 5.6, per esempio, il rilascio
che emerge al termine della finestra d'inclusione si chiamerà 5.6-rc1.
Questo rilascio indica che il momento di aggiungere nuovi componenti è
passato, e che è iniziato il periodo di stabilizzazione del prossimo kernel.

Nelle successive sei/dieci settimane, potranno essere sottoposte solo modifiche
che vanno a risolvere delle problematiche.  Occasionalmente potrà essere
consentita una modifica più consistente, ma tali occasioni sono rare.
Gli sviluppatori che tenteranno di aggiungere nuovi elementi al di fuori della
finestra di inclusione, tendenzialmente, riceveranno un accoglienza poco
amichevole. Come regola generale: se vi perdete la finestra di inclusione per
un dato componente, la cosa migliore da fare è aspettare il ciclo di sviluppo
successivo (un'eccezione può essere fatta per i driver per hardware non
supportati in precedenza; se toccano codice non facente parte di quello
attuale, che non causino regressioni e che potrebbero essere aggiunti in
sicurezza in un qualsiasi momento)

Mentre le correzioni si aprono la loro strada all'interno del ramo principale,
il ritmo delle modifiche rallenta col tempo.  Linus rilascia un nuovo
kernel -rc circa una volta alla settimana; e ne usciranno circa 6 o 9 prima
che il kernel venga considerato sufficientemente stabile e che il rilascio
finale venga fatto.  A quel punto tutto il processo ricomincerà.

Esempio: ecco com'è andato il ciclo di sviluppo della versione 5.4
(tutte le date si collocano nel 2018)


	==============  =======================================
	15 settembre	5.3 rilascio stabile
	30 settembre	5.4-rc1, finestra di inclusione chiusa
	6 ottobre	5.4-rc2
	13 ottobre	5.4-rc3
	20 ottobre	5.4-rc4
	27 ottobre	5.4-rc5
	3 novembre	5.4-rc6
	10 novembre	5.4-rc7
	17 novembre	5.4-rc8
	24 novembre	5.4 rilascio stabile
	==============  =======================================

In che modo gli sviluppatori decidono quando chiudere il ciclo di sviluppo e
creare quindi una rilascio stabile? Un metro valido è il numero di regressioni
rilevate nel precedente rilascio.  Nessun baco è il benvenuto, ma quelli che
procurano problemi su sistemi che hanno funzionato in passato sono considerati
particolarmente seri.  Per questa ragione, le modifiche che portano ad una
regressione sono viste sfavorevolmente e verranno quasi sicuramente annullate
durante il periodo di stabilizzazione.

L'obiettivo degli sviluppatori è quello di aggiustare tutte le regressioni
conosciute prima che avvenga il rilascio stabile.  Nel mondo reale, questo
tipo di perfezione difficilmente viene raggiunta; esistono troppe variabili
in un progetto di questa portata.  Arriva un punto dove ritardare il rilascio
finale peggiora la situazione; la quantità di modifiche in attesa della
prossima finestra di inclusione crescerà enormemente, creando ancor più
regressioni al giro successivo.  Quindi molti kernel 5.x escono con una
manciata di regressioni delle quali, si spera, nessuna è grave.

Una volta che un rilascio stabile è fatto, il suo costante mantenimento è
affidato al "squadra stabilità", attualmente composta da Greg Kroah-Hartman.
Questa squadra rilascia occasionalmente degli aggiornamenti relativi al
rilascio stabile usando la numerazione 5.x.y.  Per essere presa in
considerazione per un rilascio d'aggiornamento, una modifica deve:
(1) correggere un baco importante (2) essere già inserita nel ramo principale
per il prossimo sviluppo del kernel.  Solitamente, passato il loro rilascio
iniziale, i kernel ricevono aggiornamenti per più di un ciclo di sviluppo.
Quindi, per esempio, la storia del kernel 5.2 appare così (anno 2019):

	==============  ===============================
	 7 luglio	5.2 rilascio stabile
	14 luglio	5.2.1
	21 luglio	5.2.2
	26 luglio	5.2.3
	28 luglio	5.2.4
	31 luglio	5.2.5
	...		...
	11 ottobre	5.2.21
	==============  ===============================

La 5.2.21 fu l'aggiornamento finale per la versione 5.2.

Alcuni kernel sono destinati ad essere kernel a "lungo termine"; questi
riceveranno assistenza per un lungo periodo di tempo. Consultate il seguente
collegamento per avere la lista delle versioni attualmente supportate e i
relativi manutentori:

       https://www.kernel.org/category/releases.html

Questa selezione di kernel di lungo periodo sono puramente dovuti ai loro
manutentori, alla loro necessità e al tempo per tenere aggiornate proprio
quelle versioni.  Non ci sono altri kernel a lungo termine in programma per
alcun rilascio in arrivo.

patch 생명주기

Patch는 developer keyboard에서 곧바로 mainline으로 이동하지 않는다. 각 patch의 품질을 review하고 mainline에 둘 가치가 있는 변경인지 확인하는 다소 복잡하고 비공식적인 절차를 거친다. 작은 fix는 빠르게 지나갈 수 있지만 크고 논쟁적인 변경은 수년이 걸릴 수 있다. 이 절차를 이해하지 못하거나 우회하려는 시도는 개발자에게 큰 좌절을 만든다.

• Design: 실제 요구 사항과 이를 충족할 방법을 정한다. Community 없이 진행하는 경우가 많지만 가능하면 공개적으로 설계해야 나중의 재설계 시간을 줄일 수 있다.
• Early review: 관련 mailing list에 patch를 게시하고 list의 개발자에게 comment를 받는다. 잘 진행되면 major problem이 이 단계에서 드러난다.
• Wider review: mainline 준비가 가까워지면 관련 subsystem maintainer의 acceptance를 받아 maintainer subsystem tree와 -next tree에 나타난다. Acceptance가 mainline 도달을 보장하지는 않지만 더 넓은 review와 다른 작업과의 integration problem 발견으로 이어진다.
• Mainline merge: 성공한 patch는 결국 Linus Torvalds의 mainline repository에 merge된다. 이때도 새 comment와 문제가 나올 수 있으므로 developer는 신속히 대응하고 고쳐야 한다.
• Stable release: patch의 영향을 받을 수 있는 사용자 수가 크게 늘면서 또 다른 문제가 드러날 수 있다.
• Long-term maintenance: Merge 뒤 code를 잊는 행동은 community에 나쁜 인상을 준다. API 변경으로 생긴 일부 문제는 다른 개발자가 고쳐 주지만 original developer도 code가 장기간 유용하도록 계속 책임져야 한다.

대부분 maintainer에게는 본업도 있으므로 사용자의 patch merge가 최우선일 수 없다. 필요한 변경에 대한 feedback을 받았다면 수정하거나 왜 수정하지 않아야 하는지 설명한다. Review objection은 없지만 maintainer가 merge하지 않는다면 current kernel에 계속 rebase하여 cleanly apply되도록 갱신하고 review와 merge를 위해 꾸준히 다시 보낸다.

Kernel developer나 고용주가 저지르는 가장 큰 실수 중 하나는 전체 절차를 mainline merge 한 단계로 줄이려는 것이다. 이 접근은 관련된 모두에게 반드시 좌절을 만든다.

patch는 설계, 초기 공개 review, subsystem maintainer의 수용, `linux-next` 통합 검증, mainline merge, stable release와 장기 유지보수의 단계를 거칩니다. 작은 fix는 빠를 수 있지만 큰 변경은 여러 revision과 장기간의 합의가 필요합니다.

review feedback에는 code 수정이나 기술적 반론으로 응답하고, maintainer가 바쁜 경우 current kernel에 계속 rebase하여 clean하게 적용되는 series를 다시 제시해야 합니다. mainline merge는 끝이 아니라 더 많은 사용자가 code를 시험하기 시작하는 시점입니다.

Il ciclo di vita di una patch
-----------------------------

Le patch non passano direttamente dalla tastiera dello sviluppatori
al ramo principale del kernel. Esiste, invece, una procedura disegnata
per assicurare che ogni patch sia di buona qualità e desiderata nel
ramo principale.  Questo processo avviene velocemente per le correzioni
meno importanti, o, nel caso di patch ampie e controverse, va avanti per anni.
Per uno sviluppatore la maggior frustrazione viene dalla mancanza di
comprensione di questo processo o dai tentativi di aggirarlo.

Nella speranza di ridurre questa frustrazione, questo documento spiegherà
come una patch viene inserita nel kernel.  Ciò che segue è un'introduzione
che descrive il processo ideale.  Approfondimenti verranno invece trattati
più avanti.

Una patch attraversa, generalmente, le seguenti fasi:

 - Progetto. In questa fase sono stabilite quelli che sono i requisiti
   della modifica - e come verranno soddisfatti.  Il lavoro di progettazione
   viene spesso svolto senza coinvolgere la comunità, ma è meglio renderlo
   il più aperto possibile; questo può far risparmiare molto tempo evitando
   eventuali riprogettazioni successive.

 - Prima revisione. Le patch vengono pubblicate sulle liste di discussione
   interessate, e gli sviluppatori in quella lista risponderanno coi loro
   commenti.  Se si svolge correttamente, questo procedimento potrebbe far
   emergere problemi rilevanti in una patch.

 - Revisione più ampia. Quando la patch è quasi pronta per essere inserita
   nel ramo principale, un manutentore importante del sottosistema dovrebbe
   accettarla - anche se, questa accettazione non è una garanzia che la
   patch arriverà nel ramo principale. La patch sarà visibile nei sorgenti
   del sottosistema in questione e nei sorgenti -next (descritti sotto).
   Quando il processo va a buon fine, questo passo porta ad una revisione
   più estesa della patch e alla scoperta di problemi d'integrazione
   con il lavoro altrui.

-  Per favore, tenete da conto che la maggior parte dei manutentori ha
   anche un lavoro quotidiano, quindi integrare le vostre patch potrebbe
   non essere la loro priorità più alta.  Se una vostra patch riceve
   dei suggerimenti su dei cambiamenti necessari, dovreste applicare
   quei cambiamenti o giustificare perché non sono necessari.  Se la vostra
   patch non riceve alcuna critica ma non è stata integrata dal
   manutentore del driver o sottosistema, allora dovreste continuare con
   i necessari aggiornamenti per mantenere la patch aggiornata al kernel
   più recente cosicché questa possa integrarsi senza problemi; continuate
   ad inviare gli aggiornamenti per essere revisionati e integrati.

 - Inclusione nel ramo principale. Eventualmente, una buona patch verrà
   inserita all'interno nel repositorio principale, gestito da
   Linus Torvalds.  In questa fase potrebbero emergere nuovi problemi e/o
   commenti; è importante che lo sviluppatore sia collaborativo e che sistemi
   ogni questione che possa emergere.

 - Rilascio stabile. Ora, il numero di utilizzatori che sono potenzialmente
   toccati dalla patch è aumentato, quindi, ancora una volta, potrebbero
   emergere nuovi problemi.

 - Manutenzione di lungo periodo. Nonostante sia possibile che uno sviluppatore
   si dimentichi del codice dopo la sua integrazione, questo comportamento
   lascia una brutta impressione nella comunità di sviluppo.  Integrare il
   codice elimina alcuni degli oneri facenti parte della manutenzione, in
   particolare, sistemerà le problematiche causate dalle modifiche all'API.
   Ma lo sviluppatore originario dovrebbe continuare ad assumersi la
   responsabilità per il codice se quest'ultimo continua ad essere utile
   nel lungo periodo.

Uno dei più grandi errori fatti dagli sviluppatori kernel (o dai loro datori
di lavoro) è quello di cercare di ridurre tutta la procedura ad una singola
"integrazione nel remo principale".  Questo approccio inevitabilmente conduce
a una condizione di frustrazione per tutti coloro che sono coinvolti.

maintainer 계층과 신뢰 사슬

Mainline kernel repository에 patch를 merge할 수 있는 사람은 Linus Torvalds 한 명뿐이다. 하지만 2.6.38에 들어간 9,500개가 넘는 patch 중 Linus가 직접 선택한 것은 112개, 약 1.3%뿐이었다. Project가 커져 한 개발자가 모든 patch를 직접 검사하고 선택할 수 없게 되자 kernel은 trust chain을 중심으로 lieutenant system을 만들었다.

Kernel code base는 networking, architecture support, memory management, video device 같은 subsystem으로 논리적으로 나뉜다. 대부분 subsystem에는 해당 code 전체를 책임지는 maintainer가 있다. 이들은 자신이 관리하는 kernel 영역의 느슨한 gatekeeper이며 보통 mainline 포함을 위한 patch를 받아들이는 사람이다.

Subsystem maintainer는 대개 Git을 사용해 자신의 kernel source tree를 관리한다. Git, quilt, Mercurial 같은 도구는 authorship와 기타 metadata를 포함한 patch 목록을 추적하게 해 준다. Maintainer는 언제든 자신의 repository에만 있고 mainline에는 없는 patch를 식별할 수 있다.

Merge window가 열리면 top-level maintainer는 자신의 repository에서 선택한 patch를 pull해 달라고 Linus에게 요청한다. Linus가 동의하면 patch stream이 mainline repository로 올라간다. Linus가 pull에 포함된 개별 patch를 살펴보는 정도는 상황마다 다르며 때로는 매우 자세히 보지만, 일반적으로 subsystem maintainer가 나쁜 patch를 upstream으로 보내지 않을 것이라고 신뢰한다.

Subsystem maintainer도 다른 maintainer tree에서 patch를 pull할 수 있다. 예를 들어 networking tree는 network device driver, wireless networking 등의 전용 tree에 먼저 쌓인 patch로 구성된다. Repository chain 길이에 제한은 없지만 대개 두세 단계보다 길지 않다. 각 maintainer가 하위 tree 관리자를 신뢰하기 때문에 chain of trust라고 부른다.

이 system에서 patch를 kernel에 넣으려면 올바른 maintainer를 찾는 일이 핵심이다. Patch를 Linus에게 직접 보내는 것은 일반적으로 올바른 경로가 아니다.

Linus Torvalds만 mainline repository에 최종 merge할 수 있지만 모든 patch를 직접 선별하지는 않습니다. subsystem별 maintainer가 자신이 맡은 영역의 patch를 review하고 tree에 모은 뒤 상위 maintainer의 pull request를 통해 단계적으로 올립니다.

이 구조는 아래 단계 maintainer가 검증한 내용을 위 단계가 신뢰하는 chain of trust입니다. contributor가 patch를 Linus에게 곧바로 보내기보다 `MAINTAINERS`에서 올바른 subsystem과 maintainer를 찾는 이유이기도 합니다.

Come le modifiche finiscono nel Kernel
--------------------------------------

Esiste una sola persona che può inserire le patch nel repositorio principale
del kernel: Linus Torvalds.  Ma, per esempio, di tutte le 9500 patch
che entrarono nella versione 2.6.38 del kernel, solo 112 (circa
l'1,3%) furono scelte direttamente da Linus in persona.  Il progetto
del kernel è cresciuto fino a raggiungere una dimensione tale per cui
un singolo sviluppatore non può controllare e selezionare
indipendentemente ogni modifica senza essere supportato.  La via
scelta dagli sviluppatori per indirizzare tale crescita è stata quella
di utilizzare un sistema di "sottotenenti" basato sulla fiducia.

Il codice base del kernel è spezzato in una serie si sottosistemi: rete,
supporto per specifiche architetture, gestione della memoria, video e
strumenti, etc.  Molti sottosistemi hanno un manutentore designato: ovvero uno
sviluppatore che ha piena responsabilità di tutto il codice presente in quel
sottosistema.  Tali manutentori di sottosistema sono i guardiani
(in un certo senso) della parte di kernel che gestiscono; sono coloro che
(solitamente) accetteranno una patch per l'inclusione nel ramo principale
del kernel.

I manutentori di sottosistema gestiscono ciascuno la propria parte dei sorgenti
del kernel, utilizzando abitualmente (ma certamente non sempre) git.
Strumenti come git (e affini come quilt o mercurial) permettono ai manutentori
di stilare una lista delle patch, includendo informazioni sull'autore ed
altri metadati.  In ogni momento, il manutentore può individuare quale patch
nel sua repositorio non si trova nel ramo principale.

Quando la "finestra di integrazione" si apre, i manutentori di alto livello
chiederanno a Linus di "prendere" dai loro repositori le modifiche che hanno
selezionato per l'inclusione.  Se Linus acconsente, il flusso di patch si
convoglierà nel repositorio di quest ultimo, divenendo così parte del ramo
principale del kernel.  La quantità d'attenzione che Linus presta alle
singole patch ricevute durante l'operazione di integrazione varia.
È chiaro che, qualche volta, guardi più attentamente.  Ma, come regola
generale, Linus confida nel fatto che i manutentori di sottosistema non
selezionino pessime patch.

I manutentori di sottosistemi, a turno, possono "prendere" patch
provenienti da altri manutentori.  Per esempio, i sorgenti per la rete rete
sono costruiti da modifiche che si sono accumulate inizialmente nei sorgenti
dedicati ai driver per dispositivi di rete, rete senza fili, ecc.  Tale
catena di repositori può essere più o meno lunga, benché raramente ecceda
i due o tre collegamenti.  Questo processo è conosciuto come
"la catena della fiducia", perché ogni manutentore all'interno della
catena si fida di coloro che gestiscono i livelli più bassi.

Chiaramente, in un sistema come questo, l'inserimento delle patch all'interno
del kernel si basa sul trovare il manutentore giusto.  Di norma, inviare
patch direttamente a Linus non è la via giusta.

-mm과 linux-next 통합 tree

Subsystem tree chain은 patch 흐름을 안내하지만 다음 merge window의 후보인 모든 patch를 한꺼번에 보고 싶다는 요구가 생긴다. Core function prototype을 바꾸는 patch는 old form을 사용하는 다른 patch와 충돌할 수 있으므로 developer는 pending change를 미리 알아야 한다. Reviewer와 tester도 mainline landing 전에 통합된 형태에 접근해야 한다. 모든 subsystem tree를 각각 pull하는 일은 크고 오류가 나기 쉽다.

해결책은 subsystem tree를 test와 review를 위해 모은 -next tree다. 오래된 tree인 -mm은 memory management에서 시작했으며 Andrew Morton이 유지한다. 긴 subsystem tree 목록의 patch와 debugging 지원 patch를 통합한다.

-mm에는 Andrew가 직접 선택한 patch도 상당량 들어 있다. Mailing list에 게시되었거나 전용 subsystem tree가 없는 kernel 영역의 patch일 수 있다. 그래서 다른 명확한 mainline 경로가 없는 patch가 도착하는 최후의 subsystem tree처럼 동작한다. -mm에 쌓인 miscellaneous patch는 적절한 subsystem tree로 전달되거나 Linus에게 직접 보내진다. 일반 cycle에서 mainline patch의 약 5~10%가 -mm을 통해 들어간다.

Current -mm patch는 MMOTM(-mm of the moment) directory에 있다. 다만 MMOTM tree는 compile조차 되지 않을 가능성이 있어 사용이 답답할 수 있다.

다음 cycle patch 통합의 primary tree는 Stephen Rothwell이 유지하는 linux-next다. 설계상 다음 merge window가 닫힌 뒤 mainline이 어떤 모습일지 보여 주는 snapshot이다. Assemble될 때 linux-kernel과 linux-next mailing list에 공지되며 kernel.org에서 download할 수 있다.

Linux-next는 kernel development process의 필수 요소가 되었다. 특정 merge window에 들어갈 모든 patch는 window가 열리기 어느 정도 전에 linux-next에 들어가 있어야 한다.

• MMOTMhttps://www.ozlabs.org/~akpm/mmotm/
• linux-next snapshotshttps://www.kernel.org/pub/linux/kernel/next/

여러 subsystem tree의 다음 merge window 후보를 한데 모아야 API 충돌과 통합 문제를 mainline 전에 발견할 수 있습니다. `-mm`은 Andrew Morton의 patch와 여러 tree를 통합하는 오래된 시험 공간이며, MMOTM snapshot은 때로 build되지 않을 수도 있습니다.

`linux-next`는 Stephen Rothwell이 관리하며 다음 merge window 종료 뒤의 예상 mainline 모습을 매일 통합합니다. 특정 merge window를 목표로 하는 patch는 window가 열리기 충분히 전에 linux-next에 나타나 다른 subsystem과 함께 검증되어야 합니다.

Sorgenti -next
--------------

La catena di sottosistemi guida il flusso di patch all'interno del kernel,
ma solleva anche un interessante quesito: se qualcuno volesse vedere tutte le
patch pronte per la prossima finestra di integrazione?
Gli sviluppatori si interesseranno alle patch in sospeso per verificare
che non ci siano altri conflitti di cui preoccuparsi; una modifica che, per
esempio, cambia il prototipo di una funzione fondamentale del kernel andrà in
conflitto con qualsiasi altra modifica che utilizzi la vecchia versione di
quella funzione.  Revisori e tester vogliono invece avere accesso alle
modifiche nella loro totalità prima che approdino nel ramo principale del
kernel.  Uno potrebbe prendere le patch provenienti da tutti i sottosistemi
d'interesse, ma questo sarebbe un lavoro enorme e fallace.

La risposta ci viene sotto forma di sorgenti -next, dove i sottosistemi sono
raccolti per essere testati e controllati.  Il più vecchio di questi sorgenti,
gestito da Andrew Morton, è chiamato "-mm" (memory management, che è l'inizio
di tutto).  L'-mm integra patch proveniente da una lunga lista di sottosistemi;
e ha, inoltre, alcune patch destinate al supporto del debugging.

Oltre a questo, -mm contiene una raccolta significativa di patch che sono
state selezionate da Andrew direttamente.  Queste patch potrebbero essere
state inviate in una lista di discussione, o possono essere applicate ad una
parte del kernel per la quale non esiste un sottosistema dedicato.
Di conseguenza, -mm opera come una specie di sottosistema "ultima spiaggia";
se per una patch non esiste una via chiara per entrare nel ramo principale,
allora è probabile che finirà in -mm.  Le patch passate per -mm
eventualmente finiranno nel sottosistema più appropriato o saranno inviate
direttamente a Linus.  In un tipico ciclo di sviluppo, circa il 5-10% delle
patch andrà nel ramo principale attraverso -mm.

La patch -mm correnti sono disponibili nella cartella "mmotm" (-mm of
the moment) all'indirizzo:

      http://www.ozlabs.org/~akpm/mmotm/

È molto probabile che l'uso dei sorgenti MMOTM diventi un'esperienza
frustrante; ci sono buone probabilità che non compili nemmeno.

I sorgenti principali per il prossimo ciclo d'integrazione delle patch
è linux-next, gestito da Stephen Rothwell.  I sorgenti linux-next sono, per
definizione, un'istantanea di come dovrà apparire il ramo principale dopo che
la prossima finestra di inclusione si chiuderà.  I linux-next sono annunciati
sulla lista di discussione linux-kernel e linux-next nel momento in cui
vengono assemblati; e possono essere scaricate da:

	http://www.kernel.org/pub/linux/kernel/next/

Linux-next è divenuto parte integrante del processo di sviluppo del kernel;
tutte le patch incorporate durante una finestra di integrazione dovrebbero
aver trovato la propria strada in linux-next, a volte anche prima dell'apertura
della finestra di integrazione.

drivers/staging의 준비 단계

Kernel source tree의 drivers/staging/에는 kernel tree에 추가되는 과정에 있는 driver나 filesystem의 subdirectory가 많이 있다. 더 많은 작업이 필요한 동안 staging에 머물고 완성되면 kernel proper 위치로 이동할 수 있다. Linux coding 또는 quality standard에 아직 미치지 못하지만 사용자가 이용하고 개발을 추적할 가치가 있는 driver를 관리하는 방법이다.

원문 작성 당시 Greg Kroah-Hartman이 staging tree를 유지한다. 작업이 더 필요한 driver는 drivers/staging/ 아래 독립 subdirectory로 보내며 source file과 함께 TODO file을 둬야 한다. TODO에는 kernel proper acceptance에 필요한 작업과 그 driver patch에 Cc해야 할 사람 목록을 적는다. 최소한 compile에 성공해야 staging에 기여할 수 있다.

Staging은 새 driver를 mainline에 비교적 쉽게 넣어 다른 developer의 관심과 개선을 얻는 경로가 될 수 있다. 하지만 staging 진입이 끝은 아니다. 정기적으로 발전하지 않는 code는 결국 제거된다. Distribution도 staging driver enable에 소극적인 편이다. 따라서 staging은 proper mainline driver가 되는 길의 중간 정거장일 뿐이다.

`drivers/staging/`은 사용자가 시험할 가치가 있지만 coding·품질 기준을 아직 모두 충족하지 못한 driver와 filesystem을 mainline 안에서 개선하는 중간 공간입니다. 완성되면 정식 위치로 이동하고 유지되지 않으면 제거될 수 있습니다.

staging에 있다는 사실은 품질 보증이 아니라 작업이 필요하다는 명시입니다. TODO와 maintainer 지침을 따라 작은 개선부터 참여하면 실제 kernel 개발 절차와 review를 익히는 진입점이 될 수 있습니다.

Sorgenti in preparazione
------------------------

Nei sorgenti del kernel esiste la cartella drivers/staging/, dove risiedono
molte sotto-cartelle per i driver o i filesystem che stanno per essere aggiunti
al kernel.  Questi restano nella cartella drivers/staging fintanto che avranno
bisogno di maggior lavoro; una volta completato, possono essere spostate
all'interno del kernel nel posto più appropriato.  Questo è il modo di tener
traccia dei driver che non sono ancora in linea con gli standard di codifica
o qualità, ma che le persone potrebbero voler usare ugualmente e tracciarne
lo sviluppo.

Greg Kroah-Hartman attualmente gestisce i sorgenti in preparazione. I driver
che non sono completamente pronti vengono inviati a lui, e ciascun driver avrà
la propria sotto-cartella in drivers/staging/.  Assieme ai file sorgenti
dei driver, dovrebbe essere presente nella stessa cartella anche un file TODO.
Il file TODO elenca il lavoro ancora da fare su questi driver per poter essere
accettati nel kernel, e indica anche la lista di persone da inserire in copia
conoscenza per ogni modifica fatta.  Le regole attuali richiedono che i
driver debbano, come minimo, compilare adeguatamente.

La *preparazione* può essere una via relativamente facile per inserire nuovi
driver all'interno del ramo principale, dove, con un po' di fortuna, saranno
notati da altri sviluppatori e migliorati velocemente.  Entrare nella fase
di preparazione non è però la fine della storia, infatti, il codice che si
trova nella cartella staging che non mostra regolari progressi potrebbe
essere rimosso.  Le distribuzioni, inoltre, tendono a dimostrarsi relativamente
riluttanti nell'attivare driver in preparazione. Quindi lo preparazione è,
nel migliore dei casi, una tappa sulla strada verso il divenire un driver
del ramo principale.

patch 관리 도구

Kernel development는 patch collection을 여러 방향으로 이동시키는 능력에 크게 의존하므로 강력한 도구가 없으면 현재처럼 작동할 수 없다. 이 문서는 tutorial까지 다루지 않고 주요 도구를 소개한다.

Kernel community에서 압도적으로 많이 사용하는 source code management system은 Git이다. Free software community에서 개발된 distributed version control system 중 하나이며 큰 repository와 많은 patch를 효율적으로 처리해 kernel development에 잘 맞는다. 배우고 사용하기 어렵다는 평판이 있지만 계속 개선되었다. 자신의 작업에 Git을 쓰지 않더라도 다른 developer와 mainline의 변화를 따라가려면 Git 지식이 거의 필수다.

Git을 사용하지 않는 kernel developer 사이에서는 Mercurial이 가장 흔한 선택이다. Git과 많은 기능을 공유하지만 더 쉽게 느끼는 사람이 많은 interface를 제공한다.

Quilt는 source code management system이 아니라 patch management system이다. 시간에 따른 전체 history를 추적하지 않고 변화하는 code base에 대한 특정 변경 집합을 관리한다. 일부 major subsystem maintainer가 upstream용 patch를 관리하는 데 사용하며 -mm 같은 특정 종류 tree에는 가장 알맞은 도구다.

• Githttps://git-scm.com/
• Mercurialhttps://www.selenic.com/mercurial/
• Quilthttps://savannah.nongnu.org/projects/quilt/

kernel source는 Git으로 관리되며 contributor는 `git`, `quilt` 같은 도구로 patch stack과 authorship metadata를 유지합니다. 어떤 도구를 쓰든 개별 patch가 논리적으로 분리되고 최신 base에 clean하게 적용되며 review 과정의 revision을 추적할 수 있어야 합니다.

web interface와 repository mirror는 변경 이력 탐색에 유용하지만 patch 제출과 논의는 mailing list 중심입니다. 도구 선택보다 공개 review와 재현 가능한 patch 흐름을 지키는 것이 중요합니다.

Strumenti
---------

Come è possibile notare dal testo sopra, il processo di sviluppo del kernel
dipende pesantemente dalla capacità di guidare la raccolta di patch in
diverse direzioni.  L'intera cosa non funzionerebbe se non venisse svolta
con l'uso di strumenti appropriati e potenti.  Spiegare l'uso di tali
strumenti non è lo scopo di questo documento, ma c'è spazio per alcuni
consigli.

In assoluto, nella comunità del kernel, predomina l'uso di git come sistema
di gestione dei sorgenti. Git è una delle diverse tipologie di sistemi
distribuiti di controllo versione che sono stati sviluppati nella comunità
del software libero.  Esso è calibrato per lo sviluppo del kernel, e si
comporta abbastanza bene quando ha a che fare con repositori grandi e con un
vasto numero di patch.  Git ha inoltre la reputazione di essere difficile
da imparare e utilizzare, benché stia migliorando.  Agli sviluppatori
del kernel viene richiesta un po' di familiarità con git; anche se non lo
utilizzano per il proprio lavoro, hanno bisogno di git per tenersi al passo
con il lavoro degli altri sviluppatori (e con il ramo principale).

Git è ora compreso in quasi tutte le distribuzioni Linux. Esiste una sito che
potete consultare:

	http://git-scm.com/

Qui troverete i riferimenti alla documentazione e alle guide passo-passo.

Tra gli sviluppatori Kernel che non usano git, la scelta alternativa più
popolare è quasi sicuramente Mercurial:

	http://www.selenic.com/mercurial/

Mercurial condivide diverse caratteristiche con git, ma fornisce
un'interfaccia che potrebbe risultare più semplice da utilizzare.

L'altro strumento che vale la pena conoscere è Quilt:

	http://savannah.nongnu.org/projects/quilt/


Quilt è un sistema di gestione delle patch, piuttosto che un sistema
di gestione dei sorgenti.  Non mantiene uno storico degli eventi; ma piuttosto
è orientato verso il tracciamento di uno specifico insieme di modifiche
rispetto ad un codice in evoluzione.  Molti dei più grandi manutentori di
sottosistema utilizzano quilt per gestire le patch che dovrebbero essere
integrate.  Per la gestione di certe tipologie di sorgenti (-mm, per esempio),
quilt è il miglior strumento per svolgere il lavoro.

mailing list에서 협업하기

Linux kernel 개발 작업의 많은 부분이 mailing list에서 이루어진다. 하나 이상의 list에 참여하지 않고 community의 온전한 구성원으로 활동하기는 어렵다. 동시에 많은 mail에 파묻히거나 list convention을 어길 위험도 있다.

대부분 kernel mailing list는 kernel.org에서 host하지만 다른 곳의 list도 있으므로 특정 subsystem에 맞는 list는 MAINTAINERS file에서 확인한다. Core list인 linux-kernel은 하루 500 message에 이를 수 있고 noise가 많으며 대화는 매우 기술적이고 항상 친절하지는 않다. 그래도 전체 kernel community가 한자리에 모이는 유일한 곳이라 피하면 중요한 정보를 놓친다.

• Main mailbox가 아닌 별도 folder로 list mail을 받는다. 일정 기간 stream을 무시할 수 있어야 한다.
• 모든 대화를 따라가려 하지 않는다. 관심 topic과 참여자를 함께 filter한다. 긴 thread가 subject를 바꾸지 않은 채 원래 topic에서 벗어날 수 있음에 유의한다.
• 분노를 유도하는 사람에게 반응하지 말고 무시한다.
• Reply할 때 관련된 모든 사람의 Cc header를 보존한다. 명시적 요청 같은 강한 이유가 없으면 recipient를 제거하지 않으며 답하는 상대도 Cc에 있는지 확인한다.
• 질문 전에 list archive와 전체 web을 검색한다. 사전 조사를 하지 않은 질문에 개발자는 인내심을 잃을 수 있다.
• Top-posting을 피하고 인용문 사이에 답을 넣는 interleaved 또는 inline reply를 사용한다. 자세한 내용은 Documentation/process/submitting-patches.rst의 interleaved_replies 절을 본다.
• 정확한 mailing list에서 질문한다. linux-kernel은 전체 meeting point지만 모든 subsystem developer를 찾기 가장 좋은 곳은 아니다.

초보자가 흔히 틀리는 부분은 올바른 list를 찾는 일이다. Networking 질문을 linux-kernel에 올리면 대부분 networking developer가 있는 netdev에서 질문하라는 안내를 받을 가능성이 높다. SCSI, video4linux, IDE, filesystem 등에도 별도 list가 있으며 kernel source의 MAINTAINERS가 가장 좋은 출발점이다.

• Kernel mailing listshttps://subspace.kernel.org

kernel 개발은 여러 subsystem mailing list에서 진행됩니다. 모든 traffic을 읽으려 하기보다 관심 주제와 참여자를 filter하고, 답장할 때 기존 Cc를 보존하며 top-posting 대신 관련 인용문 아래에 답하는 interleaved reply를 사용합니다.

질문 전 archive와 web을 검색하고 `MAINTAINERS`로 가장 적절한 list를 찾습니다. `linux-kernel`은 전체 community의 공통 장소지만 networking, SCSI, media 같은 전문 영역은 각 list가 실제 reviewer에게 도달하는 더 좋은 경로입니다.

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

Una grossa parte del lavoro di sviluppo del Kernel Linux viene svolto tramite
le liste di discussione.  È difficile essere un membro della comunità
pienamente coinvolto se non si partecipa almeno ad una lista da qualche
parte.  Ma, le liste di discussione di Linux rappresentano un potenziale
problema per gli sviluppatori, che rischiano di venir sepolti da un mare di
email, restare incagliati nelle convenzioni in vigore nelle liste Linux,
o entrambi.

Molte delle liste di discussione del Kernel girano su vger.kernel.org;
l'elenco principale lo si trova sul sito:

	https://subspace.kernel.org

Tuttavia, esistono liste gestite altrove; controllare il file MAINTAINERS per
trovare la lista relativa ad un sottosistema specifico.

La lista di discussione principale per lo sviluppo del kernel è, ovviamente,
linux-kernel.  Questa lista è un luogo ostile dove trovarsi; i volumi possono
raggiungere i 500 messaggi al giorno, la quantità di "rumore" è elevata,
la conversazione può essere strettamente tecnica e i partecipanti non sono
sempre preoccupati di mostrare un alto livello di educazione.  Ma non esiste
altro luogo dove la comunità di sviluppo del kernel si unisce per intero;
gli sviluppatori che evitano tale lista si perderanno informazioni importanti.

Ci sono alcuni consigli che possono essere utili per sopravvivere a
linux-kernel:

- Tenete la lista in una cartella separata, piuttosto che inserirla nella
  casella di posta principale.  Così da essere in grado di ignorare il flusso
  di mail per un certo periodo di tempo.

- Non cercate di seguire ogni conversazione - nessuno lo fa.  È importante
  filtrare solo gli argomenti d'interesse (sebbene va notato che le
  conversazioni di lungo periodo possono deviare dall'argomento originario
  senza cambiare il titolo della mail) e le persone che stanno partecipando.

- Non alimentate i troll. Se qualcuno cerca di creare nervosismo, ignoratelo.

- Quando rispondete ad una mail linux-kernel (o ad altre liste) mantenete
  tutti i Cc:.  In assenza di importanti motivazioni (come una richiesta
  esplicita), non dovreste mai togliere destinatari.  Assicuratevi sempre che
  la persona alla quale state rispondendo sia presente nella lista Cc. Questa
  usanza fa si che divenga inutile chiedere esplicitamente di essere inseriti
  in copia nel rispondere al vostro messaggio.

- Cercate nell'archivio della lista (e nella rete nella sua totalità) prima
  di far domande.  Molti sviluppatori possono divenire impazienti con le
  persone che chiaramente non hanno svolto i propri compiti a casa.

- Rispondete sotto alla porzione di righe citate, così da dare un contesto alle
  vostre risposte, e quindi renderle più leggibili (in altre parole, evitate di
  rispondere in cima, ovvero prima del testo citato). Per maggiori dettagli
  leggete :ref:`Documentation/translations/it_IT/process/submitting-patches.rst
  <it_interleaved_replies>`.


- Chiedete nella lista di discussione corretta.  Linux-kernel può essere un
  punto di incontro generale, ma non è il miglior posto dove trovare
  sviluppatori da tutti i sottosistemi.

Infine, la ricerca della corretta lista di discussione è uno degli errori più
comuni per gli sviluppatori principianti.  Qualcuno che pone una domanda
relativa alla rete su linux-kernel riceverà quasi certamente il suggerimento
di chiedere sulla lista netdev, che è la lista frequentata dagli sviluppatori
di rete.  Ci sono poi altre liste per i sottosistemi SCSI, video4linux, IDE,
filesystem, etc.  Il miglior posto dove cercare una lista di discussione è il
file MAINTAINERS che si trova nei sorgenti del kernel.

kernel 개발 시작하기

개인과 회사 모두 kernel development를 어떻게 시작할지 자주 묻고, 관계의 시작을 불필요하게 어렵게 만드는 실수도 흔하다.

회사는 개발 group을 시작하기 위해 유명 developer를 채용하곤 한다. 효과적일 수 있지만 비용이 많이 들고 경험 있는 kernel developer pool을 늘리는 데에는 크게 기여하지 않는다. 시간을 투자하면 사내 developer도 Linux kernel development를 익힐 수 있다. 그러면 kernel과 회사 사정을 모두 이해하고 다른 사람까지 교육할 수 있는 group이 생기므로 중기적으로 더 이익인 경우가 많다.

개인 developer는 시작점을 찾기 어렵다. 큰 project는 부담스러워 spelling error나 사소한 coding style issue를 고치는 patch로 시험해 보고 싶을 수 있다. 하지만 이런 patch는 community 전체를 산만하게 하는 noise를 만들기 때문에 점점 좋지 않게 평가된다. Community에 자신을 소개하려는 새 developer가 원하는 반응을 얻기 어려운 방법이다.

Andrew Morton은 모든 kernel 초보자의 첫 번째 project는 손에 넣을 수 있는 모든 machine에서 kernel이 항상 완벽히 동작하도록 만드는 일이어야 한다고 조언한다. 보통 다른 사람과 협력해 문제를 고쳐야 하고 끈기가 필요할 수 있지만, 그것 자체가 kernel development의 일부다.

• Andrew Morton의 조언https://lwn.net/Articles/283982/

당장 명확한 문제를 찾지 못했다면 current regression 목록과 일반 open bug를 살펴보는 것이 좋다. 고칠 issue는 항상 충분히 많으며, 이를 해결하면서 절차를 익히고 community의 신뢰도 쌓을 수 있다.

회사는 외부 유명 개발자 한 명에게만 의존하기보다 사내 개발자가 community 절차를 익히도록 시간을 투자하면 kernel과 제품 양쪽을 이해하는 지속 가능한 team을 만들 수 있습니다.

개인은 spelling이나 의미 없는 style 수정으로 존재감을 보이기보다 자신의 장비에서 current kernel이 제대로 동작하게 만드는 실제 문제를 찾아야 합니다. regression 목록과 open bug를 해결하면 기술과 협업 절차를 함께 익히며 community의 신뢰를 얻을 수 있습니다.

Iniziare con lo sviluppo del Kernel
-----------------------------------

Sono comuni le domande sul come iniziare con lo sviluppo del kernel - sia da
singole persone che da aziende.  Altrettanto comuni sono i passi falsi che
rendono l'inizio di tale relazione più difficile di quello che dovrebbe essere.

Le aziende spesso cercano di assumere sviluppatori noti per creare un gruppo
di sviluppo iniziale.  Questo, in effetti, può essere una tecnica efficace.
Ma risulta anche essere dispendiosa e non va ad accrescere il bacino di
sviluppatori kernel con esperienza.  È possibile anche "portare a casa"
sviluppatori per accelerare lo sviluppo del kernel, dando comunque
all'investimento un po' di tempo.  Prendersi questo tempo può fornire
al datore di lavoro un gruppo di sviluppatori che comprendono sia il kernel
che l'azienda stessa, e che possono supportare la formazione di altre persone.
Nel medio periodo, questa è spesso uno delle soluzioni più proficue.

I singoli sviluppatori sono spesso, comprensibilmente, una perdita come punto
di partenza.  Iniziare con un grande progetto può rivelarsi intimidatorio;
spesso all'inizio si vuole solo verificare il terreno con qualcosa di piccolo.
Questa è una delle motivazioni per le quali molti sviluppatori saltano alla
creazione di patch che vanno a sistemare errori di battitura o
problematiche minori legate allo stile del codice.  Sfortunatamente, tali
patch creano un certo livello di rumore che distrae l'intera comunità di
sviluppo, quindi, sempre di più, esse vengono degradate.  I nuovi sviluppatori
che desiderano presentarsi alla comunità non riceveranno l'accoglienza
che vorrebbero con questi mezzi.

Andrew Morton da questo consiglio agli aspiranti sviluppatori kernel

::

     Il primo progetto per un neofita del kernel dovrebbe essere
     sicuramente quello di "assicurarsi che il kernel funzioni alla
     perfezione sempre e su tutte le macchine sulle quali potete stendere
     la vostra mano".  Solitamente il modo per fare ciò è quello di
     collaborare con gli altri nel sistemare le cose (questo richiede
     persistenza!) ma va bene - è parte dello sviluppo kernel.

(http://lwn.net/Articles/283982/).

In assenza di problemi ovvi da risolvere, si consiglia agli sviluppatori
di consultare, in generale, la lista di regressioni e di bachi aperti.
Non c'è mai carenza di problematiche bisognose di essere sistemate;
accollandosi tali questioni gli sviluppatori accumuleranno esperienza con
la procedura, ed allo stesso tempo, aumenteranno la loro rispettabilità
all'interno della comunità di sviluppo.