531 lines · plain
1.. include:: ../disclaimer-ita.rst2 3:Original: :ref:`Documentation/process/2.Process.rst <development_process>`4:Translator: Alessia Mantegazza <amantegazza@vaga.pv.it>5 6.. _it_development_process:7 8Come funziona il processo di sviluppo9=====================================10 11Lo sviluppo del Kernel agli inizi degli anno '90 era abbastanza libero, con12un numero di utenti e sviluppatori relativamente basso. Con una base13di milioni di utenti e con 2000 sviluppatori coinvolti nel giro di un anno,14il kernel da allora ha messo in atto un certo numero di procedure per rendere15lo sviluppo più agevole. È richiesta una solida conoscenza di come tale16processo si svolge per poter esserne parte attiva.17 18Il quadro d'insieme19-------------------20 21Gli sviluppatori kernel utilizzano un calendario di rilascio generico, dove22ogni due o tre mesi viene effettuata un rilascio importante del kernel.23I rilasci più recenti sono stati:24 25 ====== =================26 5.0 3 marzo, 201927 5.1 5 maggio, 201928 5.2 7 luglio, 201929 5.3 15 settembre, 201930 5.4 24 novembre, 201931 5.5 6 gennaio, 202032 ====== =================33 34Ciascun rilascio 5.x è un importante rilascio del kernel con nuove35funzionalità, modifiche interne dell'API, e molto altro. Un tipico36rilascio contiene quasi 13,000 gruppi di modifiche con ulteriori37modifiche a parecchie migliaia di linee di codice. La 5.x. è pertanto la38linea di confine nello sviluppo del kernel Linux; il kernel utilizza un sistema39di sviluppo continuo che integra costantemente nuove importanti modifiche.40 41Viene seguita una disciplina abbastanza lineare per l'inclusione delle42patch di ogni rilascio. All'inizio di ogni ciclo di sviluppo, la43"finestra di inclusione" viene dichiarata aperta. In quel momento il codice44ritenuto sufficientemente stabile(e che è accettato dalla comunità di sviluppo)45viene incluso nel ramo principale del kernel. La maggior parte delle46patch per un nuovo ciclo di sviluppo (e tutte le più importanti modifiche)47saranno inserite durante questo periodo, ad un ritmo che si attesta sulle481000 modifiche ("patch" o "gruppo di modifiche") al giorno.49 50(per inciso, vale la pena notare che i cambiamenti integrati durante la51"finestra di inclusione" non escono dal nulla; questi infatti, sono stati52raccolti e, verificati in anticipo. Il funzionamento di tale procedimento53verrà descritto dettagliatamente più avanti).54 55La finestra di inclusione resta attiva approssimativamente per due settimane.56Al termine di questo periodo, Linus Torvald dichiarerà che la finestra è57chiusa e rilascerà il primo degli "rc" del kernel.58Per il kernel che è destinato ad essere 5.6, per esempio, il rilascio59che emerge al termine della finestra d'inclusione si chiamerà 5.6-rc1.60Questo rilascio indica che il momento di aggiungere nuovi componenti è61passato, e che è iniziato il periodo di stabilizzazione del prossimo kernel.62 63Nelle successive sei/dieci settimane, potranno essere sottoposte solo modifiche64che vanno a risolvere delle problematiche. Occasionalmente potrà essere65consentita una modifica più consistente, ma tali occasioni sono rare.66Gli sviluppatori che tenteranno di aggiungere nuovi elementi al di fuori della67finestra di inclusione, tendenzialmente, riceveranno un accoglienza poco68amichevole. Come regola generale: se vi perdete la finestra di inclusione per69un dato componente, la cosa migliore da fare è aspettare il ciclo di sviluppo70successivo (un'eccezione può essere fatta per i driver per hardware non71supportati in precedenza; se toccano codice non facente parte di quello72attuale, che non causino regressioni e che potrebbero essere aggiunti in73sicurezza in un qualsiasi momento)74 75Mentre le correzioni si aprono la loro strada all'interno del ramo principale,76il ritmo delle modifiche rallenta col tempo. Linus rilascia un nuovo77kernel -rc circa una volta alla settimana; e ne usciranno circa 6 o 9 prima78che il kernel venga considerato sufficientemente stabile e che il rilascio79finale venga fatto. A quel punto tutto il processo ricomincerà.80 81Esempio: ecco com'è andato il ciclo di sviluppo della versione 5.482(tutte le date si collocano nel 2018)83 84 85 ============== =======================================86 15 settembre 5.3 rilascio stabile87 30 settembre 5.4-rc1, finestra di inclusione chiusa88 6 ottobre 5.4-rc289 13 ottobre 5.4-rc390 20 ottobre 5.4-rc491 27 ottobre 5.4-rc592 3 novembre 5.4-rc693 10 novembre 5.4-rc794 17 novembre 5.4-rc895 24 novembre 5.4 rilascio stabile96 ============== =======================================97 98In che modo gli sviluppatori decidono quando chiudere il ciclo di sviluppo e99creare quindi una rilascio stabile? Un metro valido è il numero di regressioni100rilevate nel precedente rilascio. Nessun baco è il benvenuto, ma quelli che101procurano problemi su sistemi che hanno funzionato in passato sono considerati102particolarmente seri. Per questa ragione, le modifiche che portano ad una103regressione sono viste sfavorevolmente e verranno quasi sicuramente annullate104durante il periodo di stabilizzazione.105 106L'obiettivo degli sviluppatori è quello di aggiustare tutte le regressioni107conosciute prima che avvenga il rilascio stabile. Nel mondo reale, questo108tipo di perfezione difficilmente viene raggiunta; esistono troppe variabili109in un progetto di questa portata. Arriva un punto dove ritardare il rilascio110finale peggiora la situazione; la quantità di modifiche in attesa della111prossima finestra di inclusione crescerà enormemente, creando ancor più112regressioni al giro successivo. Quindi molti kernel 5.x escono con una113manciata di regressioni delle quali, si spera, nessuna è grave.114 115Una volta che un rilascio stabile è fatto, il suo costante mantenimento è116affidato al "squadra stabilità", attualmente composta da Greg Kroah-Hartman.117Questa squadra rilascia occasionalmente degli aggiornamenti relativi al118rilascio stabile usando la numerazione 5.x.y. Per essere presa in119considerazione per un rilascio d'aggiornamento, una modifica deve:120(1) correggere un baco importante (2) essere già inserita nel ramo principale121per il prossimo sviluppo del kernel. Solitamente, passato il loro rilascio122iniziale, i kernel ricevono aggiornamenti per più di un ciclo di sviluppo.123Quindi, per esempio, la storia del kernel 5.2 appare così (anno 2019):124 125 ============== ===============================126 7 luglio 5.2 rilascio stabile127 14 luglio 5.2.1128 21 luglio 5.2.2129 26 luglio 5.2.3130 28 luglio 5.2.4131 31 luglio 5.2.5132 ... ...133 11 ottobre 5.2.21134 ============== ===============================135 136La 5.2.21 fu l'aggiornamento finale per la versione 5.2.137 138Alcuni kernel sono destinati ad essere kernel a "lungo termine"; questi139riceveranno assistenza per un lungo periodo di tempo. Consultate il seguente140collegamento per avere la lista delle versioni attualmente supportate e i141relativi manutentori:142 143 https://www.kernel.org/category/releases.html144 145Questa selezione di kernel di lungo periodo sono puramente dovuti ai loro146manutentori, alla loro necessità e al tempo per tenere aggiornate proprio147quelle versioni. Non ci sono altri kernel a lungo termine in programma per148alcun rilascio in arrivo.149 150Il ciclo di vita di una patch151-----------------------------152 153Le patch non passano direttamente dalla tastiera dello sviluppatori154al ramo principale del kernel. Esiste, invece, una procedura disegnata155per assicurare che ogni patch sia di buona qualità e desiderata nel156ramo principale. Questo processo avviene velocemente per le correzioni157meno importanti, o, nel caso di patch ampie e controverse, va avanti per anni.158Per uno sviluppatore la maggior frustrazione viene dalla mancanza di159comprensione di questo processo o dai tentativi di aggirarlo.160 161Nella speranza di ridurre questa frustrazione, questo documento spiegherà162come una patch viene inserita nel kernel. Ciò che segue è un'introduzione163che descrive il processo ideale. Approfondimenti verranno invece trattati164più avanti.165 166Una patch attraversa, generalmente, le seguenti fasi:167 168 - Progetto. In questa fase sono stabilite quelli che sono i requisiti169 della modifica - e come verranno soddisfatti. Il lavoro di progettazione170 viene spesso svolto senza coinvolgere la comunità, ma è meglio renderlo171 il più aperto possibile; questo può far risparmiare molto tempo evitando172 eventuali riprogettazioni successive.173 174 - Prima revisione. Le patch vengono pubblicate sulle liste di discussione175 interessate, e gli sviluppatori in quella lista risponderanno coi loro176 commenti. Se si svolge correttamente, questo procedimento potrebbe far177 emergere problemi rilevanti in una patch.178 179 - Revisione più ampia. Quando la patch è quasi pronta per essere inserita180 nel ramo principale, un manutentore importante del sottosistema dovrebbe181 accettarla - anche se, questa accettazione non è una garanzia che la182 patch arriverà nel ramo principale. La patch sarà visibile nei sorgenti183 del sottosistema in questione e nei sorgenti -next (descritti sotto).184 Quando il processo va a buon fine, questo passo porta ad una revisione185 più estesa della patch e alla scoperta di problemi d'integrazione186 con il lavoro altrui.187 188- Per favore, tenete da conto che la maggior parte dei manutentori ha189 anche un lavoro quotidiano, quindi integrare le vostre patch potrebbe190 non essere la loro priorità più alta. Se una vostra patch riceve191 dei suggerimenti su dei cambiamenti necessari, dovreste applicare192 quei cambiamenti o giustificare perché non sono necessari. Se la vostra193 patch non riceve alcuna critica ma non è stata integrata dal194 manutentore del driver o sottosistema, allora dovreste continuare con195 i necessari aggiornamenti per mantenere la patch aggiornata al kernel196 più recente cosicché questa possa integrarsi senza problemi; continuate197 ad inviare gli aggiornamenti per essere revisionati e integrati.198 199 - Inclusione nel ramo principale. Eventualmente, una buona patch verrà200 inserita all'interno nel repositorio principale, gestito da201 Linus Torvalds. In questa fase potrebbero emergere nuovi problemi e/o202 commenti; è importante che lo sviluppatore sia collaborativo e che sistemi203 ogni questione che possa emergere.204 205 - Rilascio stabile. Ora, il numero di utilizzatori che sono potenzialmente206 toccati dalla patch è aumentato, quindi, ancora una volta, potrebbero207 emergere nuovi problemi.208 209 - Manutenzione di lungo periodo. Nonostante sia possibile che uno sviluppatore210 si dimentichi del codice dopo la sua integrazione, questo comportamento211 lascia una brutta impressione nella comunità di sviluppo. Integrare il212 codice elimina alcuni degli oneri facenti parte della manutenzione, in213 particolare, sistemerà le problematiche causate dalle modifiche all'API.214 Ma lo sviluppatore originario dovrebbe continuare ad assumersi la215 responsabilità per il codice se quest'ultimo continua ad essere utile216 nel lungo periodo.217 218Uno dei più grandi errori fatti dagli sviluppatori kernel (o dai loro datori219di lavoro) è quello di cercare di ridurre tutta la procedura ad una singola220"integrazione nel remo principale". Questo approccio inevitabilmente conduce221a una condizione di frustrazione per tutti coloro che sono coinvolti.222 223Come le modifiche finiscono nel Kernel224--------------------------------------225 226Esiste una sola persona che può inserire le patch nel repositorio principale227del kernel: Linus Torvalds. Ma, per esempio, di tutte le 9500 patch228che entrarono nella versione 2.6.38 del kernel, solo 112 (circa229l'1,3%) furono scelte direttamente da Linus in persona. Il progetto230del kernel è cresciuto fino a raggiungere una dimensione tale per cui231un singolo sviluppatore non può controllare e selezionare232indipendentemente ogni modifica senza essere supportato. La via233scelta dagli sviluppatori per indirizzare tale crescita è stata quella234di utilizzare un sistema di "sottotenenti" basato sulla fiducia.235 236Il codice base del kernel è spezzato in una serie si sottosistemi: rete,237supporto per specifiche architetture, gestione della memoria, video e238strumenti, etc. Molti sottosistemi hanno un manutentore designato: ovvero uno239sviluppatore che ha piena responsabilità di tutto il codice presente in quel240sottosistema. Tali manutentori di sottosistema sono i guardiani241(in un certo senso) della parte di kernel che gestiscono; sono coloro che242(solitamente) accetteranno una patch per l'inclusione nel ramo principale243del kernel.244 245I manutentori di sottosistema gestiscono ciascuno la propria parte dei sorgenti246del kernel, utilizzando abitualmente (ma certamente non sempre) git.247Strumenti come git (e affini come quilt o mercurial) permettono ai manutentori248di stilare una lista delle patch, includendo informazioni sull'autore ed249altri metadati. In ogni momento, il manutentore può individuare quale patch250nel sua repositorio non si trova nel ramo principale.251 252Quando la "finestra di integrazione" si apre, i manutentori di alto livello253chiederanno a Linus di "prendere" dai loro repositori le modifiche che hanno254selezionato per l'inclusione. Se Linus acconsente, il flusso di patch si255convoglierà nel repositorio di quest ultimo, divenendo così parte del ramo256principale del kernel. La quantità d'attenzione che Linus presta alle257singole patch ricevute durante l'operazione di integrazione varia.258È chiaro che, qualche volta, guardi più attentamente. Ma, come regola259generale, Linus confida nel fatto che i manutentori di sottosistema non260selezionino pessime patch.261 262I manutentori di sottosistemi, a turno, possono "prendere" patch263provenienti da altri manutentori. Per esempio, i sorgenti per la rete rete264sono costruiti da modifiche che si sono accumulate inizialmente nei sorgenti265dedicati ai driver per dispositivi di rete, rete senza fili, ecc. Tale266catena di repositori può essere più o meno lunga, benché raramente ecceda267i due o tre collegamenti. Questo processo è conosciuto come268"la catena della fiducia", perché ogni manutentore all'interno della269catena si fida di coloro che gestiscono i livelli più bassi.270 271Chiaramente, in un sistema come questo, l'inserimento delle patch all'interno272del kernel si basa sul trovare il manutentore giusto. Di norma, inviare273patch direttamente a Linus non è la via giusta.274 275 276Sorgenti -next277--------------278 279La catena di sottosistemi guida il flusso di patch all'interno del kernel,280ma solleva anche un interessante quesito: se qualcuno volesse vedere tutte le281patch pronte per la prossima finestra di integrazione?282Gli sviluppatori si interesseranno alle patch in sospeso per verificare283che non ci siano altri conflitti di cui preoccuparsi; una modifica che, per284esempio, cambia il prototipo di una funzione fondamentale del kernel andrà in285conflitto con qualsiasi altra modifica che utilizzi la vecchia versione di286quella funzione. Revisori e tester vogliono invece avere accesso alle287modifiche nella loro totalità prima che approdino nel ramo principale del288kernel. Uno potrebbe prendere le patch provenienti da tutti i sottosistemi289d'interesse, ma questo sarebbe un lavoro enorme e fallace.290 291La risposta ci viene sotto forma di sorgenti -next, dove i sottosistemi sono292raccolti per essere testati e controllati. Il più vecchio di questi sorgenti,293gestito da Andrew Morton, è chiamato "-mm" (memory management, che è l'inizio294di tutto). L'-mm integra patch proveniente da una lunga lista di sottosistemi;295e ha, inoltre, alcune patch destinate al supporto del debugging.296 297Oltre a questo, -mm contiene una raccolta significativa di patch che sono298state selezionate da Andrew direttamente. Queste patch potrebbero essere299state inviate in una lista di discussione, o possono essere applicate ad una300parte del kernel per la quale non esiste un sottosistema dedicato.301Di conseguenza, -mm opera come una specie di sottosistema "ultima spiaggia";302se per una patch non esiste una via chiara per entrare nel ramo principale,303allora è probabile che finirà in -mm. Le patch passate per -mm304eventualmente finiranno nel sottosistema più appropriato o saranno inviate305direttamente a Linus. In un tipico ciclo di sviluppo, circa il 5-10% delle306patch andrà nel ramo principale attraverso -mm.307 308La patch -mm correnti sono disponibili nella cartella "mmotm" (-mm of309the moment) all'indirizzo:310 311 http://www.ozlabs.org/~akpm/mmotm/312 313È molto probabile che l'uso dei sorgenti MMOTM diventi un'esperienza314frustrante; ci sono buone probabilità che non compili nemmeno.315 316I sorgenti principali per il prossimo ciclo d'integrazione delle patch317è linux-next, gestito da Stephen Rothwell. I sorgenti linux-next sono, per318definizione, un'istantanea di come dovrà apparire il ramo principale dopo che319la prossima finestra di inclusione si chiuderà. I linux-next sono annunciati320sulla lista di discussione linux-kernel e linux-next nel momento in cui321vengono assemblati; e possono essere scaricate da:322 323 http://www.kernel.org/pub/linux/kernel/next/324 325Linux-next è divenuto parte integrante del processo di sviluppo del kernel;326tutte le patch incorporate durante una finestra di integrazione dovrebbero327aver trovato la propria strada in linux-next, a volte anche prima dell'apertura328della finestra di integrazione.329 330 331Sorgenti in preparazione332------------------------333 334Nei sorgenti del kernel esiste la cartella drivers/staging/, dove risiedono335molte sotto-cartelle per i driver o i filesystem che stanno per essere aggiunti336al kernel. Questi restano nella cartella drivers/staging fintanto che avranno337bisogno di maggior lavoro; una volta completato, possono essere spostate338all'interno del kernel nel posto più appropriato. Questo è il modo di tener339traccia dei driver che non sono ancora in linea con gli standard di codifica340o qualità, ma che le persone potrebbero voler usare ugualmente e tracciarne341lo sviluppo.342 343Greg Kroah-Hartman attualmente gestisce i sorgenti in preparazione. I driver344che non sono completamente pronti vengono inviati a lui, e ciascun driver avrà345la propria sotto-cartella in drivers/staging/. Assieme ai file sorgenti346dei driver, dovrebbe essere presente nella stessa cartella anche un file TODO.347Il file TODO elenca il lavoro ancora da fare su questi driver per poter essere348accettati nel kernel, e indica anche la lista di persone da inserire in copia349conoscenza per ogni modifica fatta. Le regole attuali richiedono che i350driver debbano, come minimo, compilare adeguatamente.351 352La *preparazione* può essere una via relativamente facile per inserire nuovi353driver all'interno del ramo principale, dove, con un po' di fortuna, saranno354notati da altri sviluppatori e migliorati velocemente. Entrare nella fase355di preparazione non è però la fine della storia, infatti, il codice che si356trova nella cartella staging che non mostra regolari progressi potrebbe357essere rimosso. Le distribuzioni, inoltre, tendono a dimostrarsi relativamente358riluttanti nell'attivare driver in preparazione. Quindi lo preparazione è,359nel migliore dei casi, una tappa sulla strada verso il divenire un driver360del ramo principale.361 362 363Strumenti364---------365 366Come è possibile notare dal testo sopra, il processo di sviluppo del kernel367dipende pesantemente dalla capacità di guidare la raccolta di patch in368diverse direzioni. L'intera cosa non funzionerebbe se non venisse svolta369con l'uso di strumenti appropriati e potenti. Spiegare l'uso di tali370strumenti non è lo scopo di questo documento, ma c'è spazio per alcuni371consigli.372 373In assoluto, nella comunità del kernel, predomina l'uso di git come sistema374di gestione dei sorgenti. Git è una delle diverse tipologie di sistemi375distribuiti di controllo versione che sono stati sviluppati nella comunità376del software libero. Esso è calibrato per lo sviluppo del kernel, e si377comporta abbastanza bene quando ha a che fare con repositori grandi e con un378vasto numero di patch. Git ha inoltre la reputazione di essere difficile379da imparare e utilizzare, benché stia migliorando. Agli sviluppatori380del kernel viene richiesta un po' di familiarità con git; anche se non lo381utilizzano per il proprio lavoro, hanno bisogno di git per tenersi al passo382con il lavoro degli altri sviluppatori (e con il ramo principale).383 384Git è ora compreso in quasi tutte le distribuzioni Linux. Esiste una sito che385potete consultare:386 387 http://git-scm.com/388 389Qui troverete i riferimenti alla documentazione e alle guide passo-passo.390 391Tra gli sviluppatori Kernel che non usano git, la scelta alternativa più392popolare è quasi sicuramente Mercurial:393 394 http://www.selenic.com/mercurial/395 396Mercurial condivide diverse caratteristiche con git, ma fornisce397un'interfaccia che potrebbe risultare più semplice da utilizzare.398 399L'altro strumento che vale la pena conoscere è Quilt:400 401 http://savannah.nongnu.org/projects/quilt/402 403 404Quilt è un sistema di gestione delle patch, piuttosto che un sistema405di gestione dei sorgenti. Non mantiene uno storico degli eventi; ma piuttosto406è orientato verso il tracciamento di uno specifico insieme di modifiche407rispetto ad un codice in evoluzione. Molti dei più grandi manutentori di408sottosistema utilizzano quilt per gestire le patch che dovrebbero essere409integrate. Per la gestione di certe tipologie di sorgenti (-mm, per esempio),410quilt è il miglior strumento per svolgere il lavoro.411 412 413Liste di discussione414--------------------415 416Una grossa parte del lavoro di sviluppo del Kernel Linux viene svolto tramite417le liste di discussione. È difficile essere un membro della comunità418pienamente coinvolto se non si partecipa almeno ad una lista da qualche419parte. Ma, le liste di discussione di Linux rappresentano un potenziale420problema per gli sviluppatori, che rischiano di venir sepolti da un mare di421email, restare incagliati nelle convenzioni in vigore nelle liste Linux,422o entrambi.423 424Molte delle liste di discussione del Kernel girano su vger.kernel.org;425l'elenco principale lo si trova sul sito:426 427 http://vger.kernel.org/vger-lists.html428 429Esistono liste gestite altrove; un certo numero di queste sono in430redhat.com/mailman/listinfo.431 432La lista di discussione principale per lo sviluppo del kernel è, ovviamente,433linux-kernel. Questa lista è un luogo ostile dove trovarsi; i volumi possono434raggiungere i 500 messaggi al giorno, la quantità di "rumore" è elevata,435la conversazione può essere strettamente tecnica e i partecipanti non sono436sempre preoccupati di mostrare un alto livello di educazione. Ma non esiste437altro luogo dove la comunità di sviluppo del kernel si unisce per intero;438gli sviluppatori che evitano tale lista si perderanno informazioni importanti.439 440Ci sono alcuni consigli che possono essere utili per sopravvivere a441linux-kernel:442 443- Tenete la lista in una cartella separata, piuttosto che inserirla nella444 casella di posta principale. Così da essere in grado di ignorare il flusso445 di mail per un certo periodo di tempo.446 447- Non cercate di seguire ogni conversazione - nessuno lo fa. È importante448 filtrare solo gli argomenti d'interesse (sebbene va notato che le449 conversazioni di lungo periodo possono deviare dall'argomento originario450 senza cambiare il titolo della mail) e le persone che stanno partecipando.451 452- Non alimentate i troll. Se qualcuno cerca di creare nervosismo, ignoratelo.453 454- Quando rispondete ad una mail linux-kernel (o ad altre liste) mantenete455 tutti i Cc:. In assenza di importanti motivazioni (come una richiesta456 esplicita), non dovreste mai togliere destinatari. Assicuratevi sempre che457 la persona alla quale state rispondendo sia presente nella lista Cc. Questa458 usanza fa si che divenga inutile chiedere esplicitamente di essere inseriti459 in copia nel rispondere al vostro messaggio.460 461- Cercate nell'archivio della lista (e nella rete nella sua totalità) prima462 di far domande. Molti sviluppatori possono divenire impazienti con le463 persone che chiaramente non hanno svolto i propri compiti a casa.464 465- Rispondete sotto alla porzione di righe citate, così da dare un contesto alle466 vostre risposte, e quindi renderle più leggibili (in altre parole, evitate di467 rispondere in cima, ovvero prima del testo citato). Per maggiori dettagli468 leggete :ref:`Documentation/translations/it_IT/process/submitting-patches.rst469 <it_interleaved_replies>`.470 471 472- Chiedete nella lista di discussione corretta. Linux-kernel può essere un473 punto di incontro generale, ma non è il miglior posto dove trovare474 sviluppatori da tutti i sottosistemi.475 476Infine, la ricerca della corretta lista di discussione è uno degli errori più477comuni per gli sviluppatori principianti. Qualcuno che pone una domanda478relativa alla rete su linux-kernel riceverà quasi certamente il suggerimento479di chiedere sulla lista netdev, che è la lista frequentata dagli sviluppatori480di rete. Ci sono poi altre liste per i sottosistemi SCSI, video4linux, IDE,481filesystem, etc. Il miglior posto dove cercare una lista di discussione è il482file MAINTAINERS che si trova nei sorgenti del kernel.483 484Iniziare con lo sviluppo del Kernel485-----------------------------------486 487Sono comuni le domande sul come iniziare con lo sviluppo del kernel - sia da488singole persone che da aziende. Altrettanto comuni sono i passi falsi che489rendono l'inizio di tale relazione più difficile di quello che dovrebbe essere.490 491Le aziende spesso cercano di assumere sviluppatori noti per creare un gruppo492di sviluppo iniziale. Questo, in effetti, può essere una tecnica efficace.493Ma risulta anche essere dispendiosa e non va ad accrescere il bacino di494sviluppatori kernel con esperienza. È possibile anche "portare a casa"495sviluppatori per accelerare lo sviluppo del kernel, dando comunque496all'investimento un po' di tempo. Prendersi questo tempo può fornire497al datore di lavoro un gruppo di sviluppatori che comprendono sia il kernel498che l'azienda stessa, e che possono supportare la formazione di altre persone.499Nel medio periodo, questa è spesso uno delle soluzioni più proficue.500 501I singoli sviluppatori sono spesso, comprensibilmente, una perdita come punto502di partenza. Iniziare con un grande progetto può rivelarsi intimidatorio;503spesso all'inizio si vuole solo verificare il terreno con qualcosa di piccolo.504Questa è una delle motivazioni per le quali molti sviluppatori saltano alla505creazione di patch che vanno a sistemare errori di battitura o506problematiche minori legate allo stile del codice. Sfortunatamente, tali507patch creano un certo livello di rumore che distrae l'intera comunità di508sviluppo, quindi, sempre di più, esse vengono degradate. I nuovi sviluppatori509che desiderano presentarsi alla comunità non riceveranno l'accoglienza510che vorrebbero con questi mezzi.511 512Andrew Morton da questo consiglio agli aspiranti sviluppatori kernel513 514::515 516 Il primo progetto per un neofita del kernel dovrebbe essere517 sicuramente quello di "assicurarsi che il kernel funzioni alla518 perfezione sempre e su tutte le macchine sulle quali potete stendere519 la vostra mano". Solitamente il modo per fare ciò è quello di520 collaborare con gli altri nel sistemare le cose (questo richiede521 persistenza!) ma va bene - è parte dello sviluppo kernel.522 523(http://lwn.net/Articles/283982/).524 525In assenza di problemi ovvi da risolvere, si consiglia agli sviluppatori526di consultare, in generale, la lista di regressioni e di bachi aperti.527Non c'è mai carenza di problematiche bisognose di essere sistemate;528accollandosi tali questioni gli sviluppatori accumuleranno esperienza con529la procedura, ed allo stesso tempo, aumenteranno la loro rispettabilità530all'interno della comunità di sviluppo.531