1.. include:: ../disclaimer-ita.rst 2 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 sviluppo 9===================================== 10 11Lo sviluppo del Kernel agli inizi degli anno '90 era abbastanza libero, con 12un numero di utenti e sviluppatori relativamente basso. Con una base 13di 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 rendere 15lo sviluppo più agevole. È richiesta una solida conoscenza di come tale 16processo si svolge per poter esserne parte attiva. 17 18Il quadro d'insieme 19------------------- 20 21Gli sviluppatori kernel utilizzano un calendario di rilascio generico, dove 22ogni due o tre mesi viene effettuata un rilascio importante del kernel. 23I rilasci più recenti sono stati: 24 25 ====== ================= 26 5.0 3 marzo, 2019 27 5.1 5 maggio, 2019 28 5.2 7 luglio, 2019 29 5.3 15 settembre, 2019 30 5.4 24 novembre, 2019 31 5.5 6 gennaio, 2020 32 ====== ================= 33 34Ciascun rilascio 5.x è un importante rilascio del kernel con nuove 35funzionalità, modifiche interne dell'API, e molto altro. Un tipico 36rilascio contiene quasi 13,000 gruppi di modifiche con ulteriori 37modifiche a parecchie migliaia di linee di codice. La 5.x. è pertanto la 38linea di confine nello sviluppo del kernel Linux; il kernel utilizza un sistema 39di sviluppo continuo che integra costantemente nuove importanti modifiche. 40 41Viene seguita una disciplina abbastanza lineare per l'inclusione delle 42patch di ogni rilascio. All'inizio di ogni ciclo di sviluppo, la 43"finestra di inclusione" viene dichiarata aperta. In quel momento il codice 44ritenuto sufficientemente stabile(e che è accettato dalla comunità di sviluppo) 45viene incluso nel ramo principale del kernel. La maggior parte delle 46patch per un nuovo ciclo di sviluppo (e tutte le più importanti modifiche) 47saranno inserite durante questo periodo, ad un ritmo che si attesta sulle 481000 modifiche ("patch" o "gruppo di modifiche") al giorno. 49 50(per inciso, vale la pena notare che i cambiamenti integrati durante la 51"finestra di inclusione" non escono dal nulla; questi infatti, sono stati 52raccolti e, verificati in anticipo. Il funzionamento di tale procedimento 53verrà 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 rilascio 59che 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 modifiche 64che vanno a risolvere delle problematiche. Occasionalmente potrà essere 65consentita una modifica più consistente, ma tali occasioni sono rare. 66Gli sviluppatori che tenteranno di aggiungere nuovi elementi al di fuori della 67finestra di inclusione, tendenzialmente, riceveranno un accoglienza poco 68amichevole. Come regola generale: se vi perdete la finestra di inclusione per 69un dato componente, la cosa migliore da fare è aspettare il ciclo di sviluppo 70successivo (un'eccezione può essere fatta per i driver per hardware non 71supportati in precedenza; se toccano codice non facente parte di quello 72attuale, che non causino regressioni e che potrebbero essere aggiunti in 73sicurezza 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 nuovo 77kernel -rc circa una volta alla settimana; e ne usciranno circa 6 o 9 prima 78che il kernel venga considerato sufficientemente stabile e che il rilascio 79finale venga fatto. A quel punto tutto il processo ricomincerà. 80 81Esempio: ecco com'è andato il ciclo di sviluppo della versione 5.4 82(tutte le date si collocano nel 2018) 83 84 85 ============== ======================================= 86 15 settembre 5.3 rilascio stabile 87 30 settembre 5.4-rc1, finestra di inclusione chiusa 88 6 ottobre 5.4-rc2 89 13 ottobre 5.4-rc3 90 20 ottobre 5.4-rc4 91 27 ottobre 5.4-rc5 92 3 novembre 5.4-rc6 93 10 novembre 5.4-rc7 94 17 novembre 5.4-rc8 95 24 novembre 5.4 rilascio stabile 96 ============== ======================================= 97 98In che modo gli sviluppatori decidono quando chiudere il ciclo di sviluppo e 99creare quindi una rilascio stabile? Un metro valido è il numero di regressioni 100rilevate nel precedente rilascio. Nessun baco è il benvenuto, ma quelli che 101procurano problemi su sistemi che hanno funzionato in passato sono considerati 102particolarmente seri. Per questa ragione, le modifiche che portano ad una 103regressione sono viste sfavorevolmente e verranno quasi sicuramente annullate 104durante il periodo di stabilizzazione. 105 106L'obiettivo degli sviluppatori è quello di aggiustare tutte le regressioni 107conosciute prima che avvenga il rilascio stabile. Nel mondo reale, questo 108tipo di perfezione difficilmente viene raggiunta; esistono troppe variabili 109in un progetto di questa portata. Arriva un punto dove ritardare il rilascio 110finale peggiora la situazione; la quantità di modifiche in attesa della 111prossima finestra di inclusione crescerà enormemente, creando ancor più 112regressioni al giro successivo. Quindi molti kernel 5.x escono con una 113manciata 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 al 118rilascio stabile usando la numerazione 5.x.y. Per essere presa in 119considerazione per un rilascio d'aggiornamento, una modifica deve: 120(1) correggere un baco importante (2) essere già inserita nel ramo principale 121per il prossimo sviluppo del kernel. Solitamente, passato il loro rilascio 122iniziale, 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 stabile 127 14 luglio 5.2.1 128 21 luglio 5.2.2 129 26 luglio 5.2.3 130 28 luglio 5.2.4 131 31 luglio 5.2.5 132 ... ... 133 11 ottobre 5.2.21 134 ============== =============================== 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"; questi 139riceveranno assistenza per un lungo periodo di tempo. Consultate il seguente 140collegamento per avere la lista delle versioni attualmente supportate e i 141relativi manutentori: 142 143 https://www.kernel.org/category/releases.html 144 145Questa selezione di kernel di lungo periodo sono puramente dovuti ai loro 146manutentori, alla loro necessità e al tempo per tenere aggiornate proprio 147quelle versioni. Non ci sono altri kernel a lungo termine in programma per 148alcun rilascio in arrivo. 149 150Il ciclo di vita di una patch 151----------------------------- 152 153Le patch non passano direttamente dalla tastiera dello sviluppatori 154al ramo principale del kernel. Esiste, invece, una procedura disegnata 155per assicurare che ogni patch sia di buona qualità e desiderata nel 156ramo principale. Questo processo avviene velocemente per le correzioni 157meno importanti, o, nel caso di patch ampie e controverse, va avanti per anni. 158Per uno sviluppatore la maggior frustrazione viene dalla mancanza di 159comprensione 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'introduzione 163che descrive il processo ideale. Approfondimenti verranno invece trattati 164più avanti. 165 166Una patch attraversa, generalmente, le seguenti fasi: 167 168 - Progetto. In questa fase sono stabilite quelli che sono i requisiti 169 della modifica - e come verranno soddisfatti. Il lavoro di progettazione 170 viene spesso svolto senza coinvolgere la comunità, ma è meglio renderlo 171 il più aperto possibile; questo può far risparmiare molto tempo evitando 172 eventuali riprogettazioni successive. 173 174 - Prima revisione. Le patch vengono pubblicate sulle liste di discussione 175 interessate, e gli sviluppatori in quella lista risponderanno coi loro 176 commenti. Se si svolge correttamente, questo procedimento potrebbe far 177 emergere problemi rilevanti in una patch. 178 179 - Revisione più ampia. Quando la patch è quasi pronta per essere inserita 180 nel ramo principale, un manutentore importante del sottosistema dovrebbe 181 accettarla - anche se, questa accettazione non è una garanzia che la 182 patch arriverà nel ramo principale. La patch sarà visibile nei sorgenti 183 del sottosistema in questione e nei sorgenti -next (descritti sotto). 184 Quando il processo va a buon fine, questo passo porta ad una revisione 185 più estesa della patch e alla scoperta di problemi d'integrazione 186 con il lavoro altrui. 187 188- Per favore, tenete da conto che la maggior parte dei manutentori ha 189 anche un lavoro quotidiano, quindi integrare le vostre patch potrebbe 190 non essere la loro priorità più alta. Se una vostra patch riceve 191 dei suggerimenti su dei cambiamenti necessari, dovreste applicare 192 quei cambiamenti o giustificare perché non sono necessari. Se la vostra 193 patch non riceve alcuna critica ma non è stata integrata dal 194 manutentore del driver o sottosistema, allora dovreste continuare con 195 i necessari aggiornamenti per mantenere la patch aggiornata al kernel 196 più recente cosicché questa possa integrarsi senza problemi; continuate 197 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 da 201 Linus Torvalds. In questa fase potrebbero emergere nuovi problemi e/o 202 commenti; è importante che lo sviluppatore sia collaborativo e che sistemi 203 ogni questione che possa emergere. 204 205 - Rilascio stabile. Ora, il numero di utilizzatori che sono potenzialmente 206 toccati dalla patch è aumentato, quindi, ancora una volta, potrebbero 207 emergere nuovi problemi. 208 209 - Manutenzione di lungo periodo. Nonostante sia possibile che uno sviluppatore 210 si dimentichi del codice dopo la sua integrazione, questo comportamento 211 lascia una brutta impressione nella comunità di sviluppo. Integrare il 212 codice elimina alcuni degli oneri facenti parte della manutenzione, in 213 particolare, sistemerà le problematiche causate dalle modifiche all'API. 214 Ma lo sviluppatore originario dovrebbe continuare ad assumersi la 215 responsabilità per il codice se quest'ultimo continua ad essere utile 216 nel lungo periodo. 217 218Uno dei più grandi errori fatti dagli sviluppatori kernel (o dai loro datori 219di lavoro) è quello di cercare di ridurre tutta la procedura ad una singola 220"integrazione nel remo principale". Questo approccio inevitabilmente conduce 221a una condizione di frustrazione per tutti coloro che sono coinvolti. 222 223Come le modifiche finiscono nel Kernel 224-------------------------------------- 225 226Esiste una sola persona che può inserire le patch nel repositorio principale 227del kernel: Linus Torvalds. Ma, per esempio, di tutte le 9500 patch 228che entrarono nella versione 2.6.38 del kernel, solo 112 (circa 229l'1,3%) furono scelte direttamente da Linus in persona. Il progetto 230del kernel è cresciuto fino a raggiungere una dimensione tale per cui 231un singolo sviluppatore non può controllare e selezionare 232indipendentemente ogni modifica senza essere supportato. La via 233scelta dagli sviluppatori per indirizzare tale crescita è stata quella 234di 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 e 238strumenti, etc. Molti sottosistemi hanno un manutentore designato: ovvero uno 239sviluppatore che ha piena responsabilità di tutto il codice presente in quel 240sottosistema. Tali manutentori di sottosistema sono i guardiani 241(in un certo senso) della parte di kernel che gestiscono; sono coloro che 242(solitamente) accetteranno una patch per l'inclusione nel ramo principale 243del kernel. 244 245I manutentori di sottosistema gestiscono ciascuno la propria parte dei sorgenti 246del kernel, utilizzando abitualmente (ma certamente non sempre) git. 247Strumenti come git (e affini come quilt o mercurial) permettono ai manutentori 248di stilare una lista delle patch, includendo informazioni sull'autore ed 249altri metadati. In ogni momento, il manutentore può individuare quale patch 250nel sua repositorio non si trova nel ramo principale. 251 252Quando la "finestra di integrazione" si apre, i manutentori di alto livello 253chiederanno a Linus di "prendere" dai loro repositori le modifiche che hanno 254selezionato per l'inclusione. Se Linus acconsente, il flusso di patch si 255convoglierà nel repositorio di quest ultimo, divenendo così parte del ramo 256principale del kernel. La quantità d'attenzione che Linus presta alle 257singole patch ricevute durante l'operazione di integrazione varia. 258È chiaro che, qualche volta, guardi più attentamente. Ma, come regola 259generale, Linus confida nel fatto che i manutentori di sottosistema non 260selezionino pessime patch. 261 262I manutentori di sottosistemi, a turno, possono "prendere" patch 263provenienti da altri manutentori. Per esempio, i sorgenti per la rete rete 264sono costruiti da modifiche che si sono accumulate inizialmente nei sorgenti 265dedicati ai driver per dispositivi di rete, rete senza fili, ecc. Tale 266catena di repositori può essere più o meno lunga, benché raramente ecceda 267i due o tre collegamenti. Questo processo è conosciuto come 268"la catena della fiducia", perché ogni manutentore all'interno della 269catena si fida di coloro che gestiscono i livelli più bassi. 270 271Chiaramente, in un sistema come questo, l'inserimento delle patch all'interno 272del kernel si basa sul trovare il manutentore giusto. Di norma, inviare 273patch direttamente a Linus non è la via giusta. 274 275 276Sorgenti -next 277-------------- 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 le 281patch pronte per la prossima finestra di integrazione? 282Gli sviluppatori si interesseranno alle patch in sospeso per verificare 283che non ci siano altri conflitti di cui preoccuparsi; una modifica che, per 284esempio, cambia il prototipo di una funzione fondamentale del kernel andrà in 285conflitto con qualsiasi altra modifica che utilizzi la vecchia versione di 286quella funzione. Revisori e tester vogliono invece avere accesso alle 287modifiche nella loro totalità prima che approdino nel ramo principale del 288kernel. Uno potrebbe prendere le patch provenienti da tutti i sottosistemi 289d'interesse, ma questo sarebbe un lavoro enorme e fallace. 290 291La risposta ci viene sotto forma di sorgenti -next, dove i sottosistemi sono 292raccolti per essere testati e controllati. Il più vecchio di questi sorgenti, 293gestito da Andrew Morton, è chiamato "-mm" (memory management, che è l'inizio 294di 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 sono 298state selezionate da Andrew direttamente. Queste patch potrebbero essere 299state inviate in una lista di discussione, o possono essere applicate ad una 300parte 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 -mm 304eventualmente finiranno nel sottosistema più appropriato o saranno inviate 305direttamente a Linus. In un tipico ciclo di sviluppo, circa il 5-10% delle 306patch andrà nel ramo principale attraverso -mm. 307 308La patch -mm correnti sono disponibili nella cartella "mmotm" (-mm of 309the moment) all'indirizzo: 310 311 http://www.ozlabs.org/~akpm/mmotm/ 312 313È molto probabile che l'uso dei sorgenti MMOTM diventi un'esperienza 314frustrante; ci sono buone probabilità che non compili nemmeno. 315 316I sorgenti principali per il prossimo ciclo d'integrazione delle patch 317è linux-next, gestito da Stephen Rothwell. I sorgenti linux-next sono, per 318definizione, un'istantanea di come dovrà apparire il ramo principale dopo che 319la prossima finestra di inclusione si chiuderà. I linux-next sono annunciati 320sulla lista di discussione linux-kernel e linux-next nel momento in cui 321vengono 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 dovrebbero 327aver trovato la propria strada in linux-next, a volte anche prima dell'apertura 328della finestra di integrazione. 329 330 331Sorgenti in preparazione 332------------------------ 333 334Nei sorgenti del kernel esiste la cartella drivers/staging/, dove risiedono 335molte sotto-cartelle per i driver o i filesystem che stanno per essere aggiunti 336al kernel. Questi restano nella cartella drivers/staging fintanto che avranno 337bisogno di maggior lavoro; una volta completato, possono essere spostate 338all'interno del kernel nel posto più appropriato. Questo è il modo di tener 339traccia dei driver che non sono ancora in linea con gli standard di codifica 340o qualità, ma che le persone potrebbero voler usare ugualmente e tracciarne 341lo sviluppo. 342 343Greg Kroah-Hartman attualmente gestisce i sorgenti in preparazione. I driver 344che non sono completamente pronti vengono inviati a lui, e ciascun driver avrà 345la propria sotto-cartella in drivers/staging/. Assieme ai file sorgenti 346dei 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 essere 348accettati nel kernel, e indica anche la lista di persone da inserire in copia 349conoscenza per ogni modifica fatta. Le regole attuali richiedono che i 350driver debbano, come minimo, compilare adeguatamente. 351 352La *preparazione* può essere una via relativamente facile per inserire nuovi 353driver all'interno del ramo principale, dove, con un po' di fortuna, saranno 354notati da altri sviluppatori e migliorati velocemente. Entrare nella fase 355di preparazione non è però la fine della storia, infatti, il codice che si 356trova nella cartella staging che non mostra regolari progressi potrebbe 357essere rimosso. Le distribuzioni, inoltre, tendono a dimostrarsi relativamente 358riluttanti nell'attivare driver in preparazione. Quindi lo preparazione è, 359nel migliore dei casi, una tappa sulla strada verso il divenire un driver 360del ramo principale. 361 362 363Strumenti 364--------- 365 366Come è possibile notare dal testo sopra, il processo di sviluppo del kernel 367dipende pesantemente dalla capacità di guidare la raccolta di patch in 368diverse direzioni. L'intera cosa non funzionerebbe se non venisse svolta 369con l'uso di strumenti appropriati e potenti. Spiegare l'uso di tali 370strumenti non è lo scopo di questo documento, ma c'è spazio per alcuni 371consigli. 372 373In assoluto, nella comunità del kernel, predomina l'uso di git come sistema 374di gestione dei sorgenti. Git è una delle diverse tipologie di sistemi 375distribuiti di controllo versione che sono stati sviluppati nella comunità 376del software libero. Esso è calibrato per lo sviluppo del kernel, e si 377comporta abbastanza bene quando ha a che fare con repositori grandi e con un 378vasto numero di patch. Git ha inoltre la reputazione di essere difficile 379da imparare e utilizzare, benché stia migliorando. Agli sviluppatori 380del kernel viene richiesta un po' di familiarità con git; anche se non lo 381utilizzano per il proprio lavoro, hanno bisogno di git per tenersi al passo 382con il lavoro degli altri sviluppatori (e con il ramo principale). 383 384Git è ora compreso in quasi tutte le distribuzioni Linux. Esiste una sito che 385potete 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 fornisce 397un'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 sistema 405di gestione dei sorgenti. Non mantiene uno storico degli eventi; ma piuttosto 406è orientato verso il tracciamento di uno specifico insieme di modifiche 407rispetto ad un codice in evoluzione. Molti dei più grandi manutentori di 408sottosistema utilizzano quilt per gestire le patch che dovrebbero essere 409integrate. Per la gestione di certe tipologie di sorgenti (-mm, per esempio), 410quilt è il miglior strumento per svolgere il lavoro. 411 412 413Liste di discussione 414-------------------- 415 416Una grossa parte del lavoro di sviluppo del Kernel Linux viene svolto tramite 417le liste di discussione. È difficile essere un membro della comunità 418pienamente coinvolto se non si partecipa almeno ad una lista da qualche 419parte. Ma, le liste di discussione di Linux rappresentano un potenziale 420problema per gli sviluppatori, che rischiano di venir sepolti da un mare di 421email, 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.html 428 429Esistono liste gestite altrove; un certo numero di queste sono in 430redhat.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 possono 434raggiungere i 500 messaggi al giorno, la quantità di "rumore" è elevata, 435la conversazione può essere strettamente tecnica e i partecipanti non sono 436sempre preoccupati di mostrare un alto livello di educazione. Ma non esiste 437altro 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 a 441linux-kernel: 442 443- Tenete la lista in una cartella separata, piuttosto che inserirla nella 444 casella di posta principale. Così da essere in grado di ignorare il flusso 445 di mail per un certo periodo di tempo. 446 447- Non cercate di seguire ogni conversazione - nessuno lo fa. È importante 448 filtrare solo gli argomenti d'interesse (sebbene va notato che le 449 conversazioni di lungo periodo possono deviare dall'argomento originario 450 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) mantenete 455 tutti i Cc:. In assenza di importanti motivazioni (come una richiesta 456 esplicita), non dovreste mai togliere destinatari. Assicuratevi sempre che 457 la persona alla quale state rispondendo sia presente nella lista Cc. Questa 458 usanza fa si che divenga inutile chiedere esplicitamente di essere inseriti 459 in copia nel rispondere al vostro messaggio. 460 461- Cercate nell'archivio della lista (e nella rete nella sua totalità) prima 462 di far domande. Molti sviluppatori possono divenire impazienti con le 463 persone che chiaramente non hanno svolto i propri compiti a casa. 464 465- Evitate il *top-posting* (cioè la pratica di mettere la vostra risposta sopra 466 alla frase alla quale state rispondendo). Ciò renderebbe la vostra risposta 467 difficile da leggere e genera scarsa impressione. 468 469- Chiedete nella lista di discussione corretta. Linux-kernel può essere un 470 punto di incontro generale, ma non è il miglior posto dove trovare 471 sviluppatori da tutti i sottosistemi. 472 473Infine, la ricerca della corretta lista di discussione è uno degli errori più 474comuni per gli sviluppatori principianti. Qualcuno che pone una domanda 475relativa alla rete su linux-kernel riceverà quasi certamente il suggerimento 476di chiedere sulla lista netdev, che è la lista frequentata dagli sviluppatori 477di rete. Ci sono poi altre liste per i sottosistemi SCSI, video4linux, IDE, 478filesystem, etc. Il miglior posto dove cercare una lista di discussione è il 479file MAINTAINERS che si trova nei sorgenti del kernel. 480 481Iniziare con lo sviluppo del Kernel 482----------------------------------- 483 484Sono comuni le domande sul come iniziare con lo sviluppo del kernel - sia da 485singole persone che da aziende. Altrettanto comuni sono i passi falsi che 486rendono l'inizio di tale relazione più difficile di quello che dovrebbe essere. 487 488Le aziende spesso cercano di assumere sviluppatori noti per creare un gruppo 489di sviluppo iniziale. Questo, in effetti, può essere una tecnica efficace. 490Ma risulta anche essere dispendiosa e non va ad accrescere il bacino di 491sviluppatori kernel con esperienza. È possibile anche "portare a casa" 492sviluppatori per accelerare lo sviluppo del kernel, dando comunque 493all'investimento un po' di tempo. Prendersi questo tempo può fornire 494al datore di lavoro un gruppo di sviluppatori che comprendono sia il kernel 495che l'azienda stessa, e che possono supportare la formazione di altre persone. 496Nel medio periodo, questa è spesso uno delle soluzioni più proficue. 497 498I singoli sviluppatori sono spesso, comprensibilmente, una perdita come punto 499di partenza. Iniziare con un grande progetto può rivelarsi intimidatorio; 500spesso all'inizio si vuole solo verificare il terreno con qualcosa di piccolo. 501Questa è una delle motivazioni per le quali molti sviluppatori saltano alla 502creazione di patch che vanno a sistemare errori di battitura o 503problematiche minori legate allo stile del codice. Sfortunatamente, tali 504patch creano un certo livello di rumore che distrae l'intera comunità di 505sviluppo, quindi, sempre di più, esse vengono degradate. I nuovi sviluppatori 506che desiderano presentarsi alla comunità non riceveranno l'accoglienza 507che vorrebbero con questi mezzi. 508 509Andrew Morton da questo consiglio agli aspiranti sviluppatori kernel 510 511:: 512 513 Il primo progetto per un neofita del kernel dovrebbe essere 514 sicuramente quello di "assicurarsi che il kernel funzioni alla 515 perfezione sempre e su tutte le macchine sulle quali potete stendere 516 la vostra mano". Solitamente il modo per fare ciò è quello di 517 collaborare con gli altri nel sistemare le cose (questo richiede 518 persistenza!) ma va bene - è parte dello sviluppo kernel. 519 520(http://lwn.net/Articles/283982/). 521 522In assenza di problemi ovvi da risolvere, si consiglia agli sviluppatori 523di consultare, in generale, la lista di regressioni e di bachi aperti. 524Non c'è mai carenza di problematiche bisognose di essere sistemate; 525accollandosi tali questioni gli sviluppatori accumuleranno esperienza con 526la procedura, ed allo stesso tempo, aumenteranno la loro rispettabilità 527all'interno della comunità di sviluppo. 528