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	15 settembre	5.2 rilascio stabile FIXME settembre è sbagliato
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.  Al momento in cui
140scriviamo, i manutentori dei kernel stabili a lungo termine sono:
141
142	======  ================================  ==========================================
143	3.16	Ben Hutchings			  (kernel stabile molto più a lungo termine)
144	4.4	Greg Kroah-Hartman e Sasha Levin  (kernel stabile molto più a lungo termine)
145	4.9	Greg Kroah-Hartman e Sasha Levin
146	4.14	Greg Kroah-Hartman e Sasha Levin
147	4.19	Greg Kroah-Hartman e Sasha Levin
148	5.4i	Greg Kroah-Hartman e Sasha Levin
149	======  ================================  ==========================================
150
151
152Questa selezione di kernel di lungo periodo sono puramente dovuti ai loro
153manutentori, alla loro necessità e al tempo per tenere aggiornate proprio
154quelle versioni.  Non ci sono altri kernel a lungo termine in programma per
155alcun rilascio in arrivo.
156
157Il ciclo di vita di una patch
158-----------------------------
159
160Le patch non passano direttamente dalla tastiera dello sviluppatori
161al ramo principale del kernel. Esiste, invece, una procedura disegnata
162per assicurare che ogni patch sia di buona qualità e desiderata nel
163ramo principale.  Questo processo avviene velocemente per le correzioni
164meno importanti, o, nel caso di patch ampie e controverse, va avanti per anni.
165Per uno sviluppatore la maggior frustrazione viene dalla mancanza di
166comprensione di questo processo o dai tentativi di aggirarlo.
167
168Nella speranza di ridurre questa frustrazione, questo documento spiegherà
169come una patch viene inserita nel kernel.  Ciò che segue è un'introduzione
170che descrive il processo ideale.  Approfondimenti verranno invece trattati
171più avanti.
172
173Una patch attraversa, generalmente, le seguenti fasi:
174
175 - Progetto. In questa fase sono stabilite quelli che sono i requisiti
176   della modifica - e come verranno soddisfatti.  Il lavoro di progettazione
177   viene spesso svolto senza coinvolgere la comunità, ma è meglio renderlo
178   il più aperto possibile; questo può far risparmiare molto tempo evitando
179   eventuali riprogettazioni successive.
180
181 - Prima revisione. Le patch vengono pubblicate sulle liste di discussione
182   interessate, e gli sviluppatori in quella lista risponderanno coi loro
183   commenti.  Se si svolge correttamente, questo procedimento potrebbe far
184   emergere problemi rilevanti in una patch.
185
186 - Revisione più ampia. Quando la patch è quasi pronta per essere inserita
187   nel ramo principale, un manutentore importante del sottosistema dovrebbe
188   accettarla - anche se, questa accettazione non è una garanzia che la
189   patch arriverà nel ramo principale. La patch sarà visibile nei sorgenti
190   del sottosistema in questione e nei sorgenti -next (descritti sotto).
191   Quando il processo va a buon fine, questo passo porta ad una revisione
192   più estesa della patch e alla scoperta di problemi d'integrazione
193   con il lavoro altrui.
194
195-  Per favore, tenete da conto che la maggior parte dei manutentori ha
196   anche un lavoro quotidiano, quindi integrare le vostre patch potrebbe
197   non essere la loro priorità più alta.  Se una vostra patch riceve
198   dei suggerimenti su dei cambiamenti necessari, dovreste applicare
199   quei cambiamenti o giustificare perché non sono necessari.  Se la vostra
200   patch non riceve alcuna critica ma non è stata integrata dal
201   manutentore del driver o sottosistema, allora dovreste continuare con
202   i necessari aggiornamenti per mantenere la patch aggiornata al kernel
203   più recente cosicché questa possa integrarsi senza problemi; continuate
204   ad inviare gli aggiornamenti per essere revisionati e integrati.
205
206 - Inclusione nel ramo principale. Eventualmente, una buona patch verrà
207   inserita all'interno nel repositorio principale, gestito da
208   Linus Torvalds.  In questa fase potrebbero emergere nuovi problemi e/o
209   commenti; è importante che lo sviluppatore sia collaborativo e che sistemi
210   ogni questione che possa emergere.
211
212 - Rilascio stabile. Ora, il numero di utilizzatori che sono potenzialmente
213   toccati dalla patch è aumentato, quindi, ancora una volta, potrebbero
214   emergere nuovi problemi.
215
216 - Manutenzione di lungo periodo. Nonostante sia possibile che uno sviluppatore
217   si dimentichi del codice dopo la sua integrazione, questo comportamento
218   lascia una brutta impressione nella comunità di sviluppo.  Integrare il
219   codice elimina alcuni degli oneri facenti parte della manutenzione, in
220   particolare, sistemerà le problematiche causate dalle modifiche all'API.
221   Ma lo sviluppatore originario dovrebbe continuare ad assumersi la
222   responsabilità per il codice se quest'ultimo continua ad essere utile
223   nel lungo periodo.
224
225Uno dei più grandi errori fatti dagli sviluppatori kernel (o dai loro datori
226di lavoro) è quello di cercare di ridurre tutta la procedura ad una singola
227"integrazione nel remo principale".  Questo approccio inevitabilmente conduce
228a una condizione di frustrazione per tutti coloro che sono coinvolti.
229
230Come le modifiche finiscono nel Kernel
231--------------------------------------
232
233Esiste una sola persona che può inserire le patch nel repositorio principale
234del kernel: Linus Torvalds.  Ma, per esempio, di tutte le 9500 patch
235che entrarono nella versione 2.6.38 del kernel, solo 112 (circa
236l'1,3%) furono scelte direttamente da Linus in persona.  Il progetto
237del kernel è cresciuto fino a raggiungere una dimensione tale per cui
238un singolo sviluppatore non può controllare e selezionare
239indipendentemente ogni modifica senza essere supportato.  La via
240scelta dagli sviluppatori per indirizzare tale crescita è stata quella
241di utilizzare un sistema di "sottotenenti" basato sulla fiducia.
242
243Il codice base del kernel è spezzato in una serie si sottosistemi: rete,
244supporto per specifiche architetture, gestione della memoria, video e
245strumenti, etc.  Molti sottosistemi hanno un manutentore designato: ovvero uno
246sviluppatore che ha piena responsabilità di tutto il codice presente in quel
247sottosistema.  Tali manutentori di sottosistema sono i guardiani
248(in un certo senso) della parte di kernel che gestiscono; sono coloro che
249(solitamente) accetteranno una patch per l'inclusione nel ramo principale
250del kernel.
251
252I manutentori di sottosistema gestiscono ciascuno la propria parte dei sorgenti
253del kernel, utilizzando abitualmente (ma certamente non sempre) git.
254Strumenti come git (e affini come quilt o mercurial) permettono ai manutentori
255di stilare una lista delle patch, includendo informazioni sull'autore ed
256altri metadati.  In ogni momento, il manutentore può individuare quale patch
257nel sua repositorio non si trova nel ramo principale.
258
259Quando la "finestra di integrazione" si apre, i manutentori di alto livello
260chiederanno a Linus di "prendere" dai loro repositori le modifiche che hanno
261selezionato per l'inclusione.  Se Linus acconsente, il flusso di patch si
262convoglierà nel repositorio di quest ultimo, divenendo così parte del ramo
263principale del kernel.  La quantità d'attenzione che Linus presta alle
264singole patch ricevute durante l'operazione di integrazione varia.
265È chiaro che, qualche volta, guardi più attentamente.  Ma, come regola
266generale, Linus confida nel fatto che i manutentori di sottosistema non
267selezionino pessime patch.
268
269I manutentori di sottosistemi, a turno, possono "prendere" patch
270provenienti da altri manutentori.  Per esempio, i sorgenti per la rete rete
271sono costruiti da modifiche che si sono accumulate inizialmente nei sorgenti
272dedicati ai driver per dispositivi di rete, rete senza fili, ecc.  Tale
273catena di repositori può essere più o meno lunga, benché raramente ecceda
274i due o tre collegamenti.  Questo processo è conosciuto come
275"la catena della fiducia", perché ogni manutentore all'interno della
276catena si fida di coloro che gestiscono i livelli più bassi.
277
278Chiaramente, in un sistema come questo, l'inserimento delle patch all'interno
279del kernel si basa sul trovare il manutentore giusto.  Di norma, inviare
280patch direttamente a Linus non è la via giusta.
281
282
283Sorgenti -next
284--------------
285
286La catena di sottosistemi guida il flusso di patch all'interno del kernel,
287ma solleva anche un interessante quesito: se qualcuno volesse vedere tutte le
288patch pronte per la prossima finestra di integrazione?
289Gli sviluppatori si interesseranno alle patch in sospeso per verificare
290che non ci siano altri conflitti di cui preoccuparsi; una modifica che, per
291esempio, cambia il prototipo di una funzione fondamentale del kernel andrà in
292conflitto con qualsiasi altra modifica che utilizzi la vecchia versione di
293quella funzione.  Revisori e tester vogliono invece avere accesso alle
294modifiche nella loro totalità prima che approdino nel ramo principale del
295kernel.  Uno potrebbe prendere le patch provenienti da tutti i sottosistemi
296d'interesse, ma questo sarebbe un lavoro enorme e fallace.
297
298La risposta ci viene sotto forma di sorgenti -next, dove i sottosistemi sono
299raccolti per essere testati e controllati.  Il più vecchio di questi sorgenti,
300gestito da Andrew Morton, è chiamato "-mm" (memory management, che è l'inizio
301di tutto).  L'-mm integra patch proveniente da una lunga lista di sottosistemi;
302e ha, inoltre, alcune patch destinate al supporto del debugging.
303
304Oltre a questo, -mm contiene una raccolta significativa di patch che sono
305state selezionate da Andrew direttamente.  Queste patch potrebbero essere
306state inviate in una lista di discussione, o possono essere applicate ad una
307parte del kernel per la quale non esiste un sottosistema dedicato.
308Di conseguenza, -mm opera come una specie di sottosistema "ultima spiaggia";
309se per una patch non esiste una via chiara per entrare nel ramo principale,
310allora è probabile che finirà in -mm.  Le patch passate per -mm
311eventualmente finiranno nel sottosistema più appropriato o saranno inviate
312direttamente a Linus.  In un tipico ciclo di sviluppo, circa il 5-10% delle
313patch andrà nel ramo principale attraverso -mm.
314
315La patch -mm correnti sono disponibili nella cartella "mmotm" (-mm of
316the moment) all'indirizzo:
317
318      http://www.ozlabs.org/~akpm/mmotm/
319
320È molto probabile che l'uso dei sorgenti MMOTM diventi un'esperienza
321frustrante; ci sono buone probabilità che non compili nemmeno.
322
323I sorgenti principali per il prossimo ciclo d'integrazione delle patch
324è linux-next, gestito da Stephen Rothwell.  I sorgenti linux-next sono, per
325definizione, un'istantanea di come dovrà apparire il ramo principale dopo che
326la prossima finestra di inclusione si chiuderà.  I linux-next sono annunciati
327sulla lista di discussione linux-kernel e linux-next nel momento in cui
328vengono assemblati; e possono essere scaricate da:
329
330	http://www.kernel.org/pub/linux/kernel/next/
331
332Linux-next è divenuto parte integrante del processo di sviluppo del kernel;
333tutte le patch incorporate durante una finestra di integrazione dovrebbero
334aver trovato la propria strada in linux-next, a volte anche prima dell'apertura
335della finestra di integrazione.
336
337
338Sorgenti in preparazione
339------------------------
340
341Nei sorgenti del kernel esiste la cartella drivers/staging/, dove risiedono
342molte sotto-cartelle per i driver o i filesystem che stanno per essere aggiunti
343al kernel.  Questi restano nella cartella drivers/staging fintanto che avranno
344bisogno di maggior lavoro; una volta completato, possono essere spostate
345all'interno del kernel nel posto più appropriato.  Questo è il modo di tener
346traccia dei driver che non sono ancora in linea con gli standard di codifica
347o qualità, ma che le persone potrebbero voler usare ugualmente e tracciarne
348lo sviluppo.
349
350Greg Kroah-Hartman attualmente gestisce i sorgenti in preparazione. I driver
351che non sono completamente pronti vengono inviati a lui, e ciascun driver avrà
352la propria sotto-cartella in drivers/staging/.  Assieme ai file sorgenti
353dei driver, dovrebbe essere presente nella stessa cartella anche un file TODO.
354Il file TODO elenca il lavoro ancora da fare su questi driver per poter essere
355accettati nel kernel, e indica anche la lista di persone da inserire in copia
356conoscenza per ogni modifica fatta.  Le regole attuali richiedono che i
357driver debbano, come minimo, compilare adeguatamente.
358
359La *preparazione* può essere una via relativamente facile per inserire nuovi
360driver all'interno del ramo principale, dove, con un po' di fortuna, saranno
361notati da altri sviluppatori e migliorati velocemente.  Entrare nella fase
362di preparazione non è però la fine della storia, infatti, il codice che si
363trova nella cartella staging che non mostra regolari progressi potrebbe
364essere rimosso.  Le distribuzioni, inoltre, tendono a dimostrarsi relativamente
365riluttanti nell'attivare driver in preparazione. Quindi lo preparazione è,
366nel migliore dei casi, una tappa sulla strada verso il divenire un driver
367del ramo principale.
368
369
370Strumenti
371---------
372
373Come è possibile notare dal testo sopra, il processo di sviluppo del kernel
374dipende pesantemente dalla capacità di guidare la raccolta di patch in
375diverse direzioni.  L'intera cosa non funzionerebbe se non venisse svolta
376con l'uso di strumenti appropriati e potenti.  Spiegare l'uso di tali
377strumenti non è lo scopo di questo documento, ma c'è spazio per alcuni
378consigli.
379
380In assoluto, nella comunità del kernel, predomina l'uso di git come sistema
381di gestione dei sorgenti. Git è una delle diverse tipologie di sistemi
382distribuiti di controllo versione che sono stati sviluppati nella comunità
383del software libero.  Esso è calibrato per lo sviluppo del kernel, e si
384comporta abbastanza bene quando ha a che fare con repositori grandi e con un
385vasto numero di patch.  Git ha inoltre la reputazione di essere difficile
386da imparare e utilizzare, benché stia migliorando.  Agli sviluppatori
387del kernel viene richiesta un po' di familiarità con git; anche se non lo
388utilizzano per il proprio lavoro, hanno bisogno di git per tenersi al passo
389con il lavoro degli altri sviluppatori (e con il ramo principale).
390
391Git è ora compreso in quasi tutte le distribuzioni Linux. Esiste una sito che
392potete consultare:
393
394	http://git-scm.com/
395
396Qui troverete i riferimenti alla documentazione e alle guide passo-passo.
397
398Tra gli sviluppatori Kernel che non usano git, la scelta alternativa più
399popolare è quasi sicuramente Mercurial:
400
401	http://www.selenic.com/mercurial/
402
403Mercurial condivide diverse caratteristiche con git, ma fornisce
404un'interfaccia che potrebbe risultare più semplice da utilizzare.
405
406L'altro strumento che vale la pena conoscere è Quilt:
407
408	http://savannah.nongnu.org/projects/quilt/
409
410
411Quilt è un sistema di gestione delle patch, piuttosto che un sistema
412di gestione dei sorgenti.  Non mantiene uno storico degli eventi; ma piuttosto
413è orientato verso il tracciamento di uno specifico insieme di modifiche
414rispetto ad un codice in evoluzione.  Molti dei più grandi manutentori di
415sottosistema utilizzano quilt per gestire le patch che dovrebbero essere
416integrate.  Per la gestione di certe tipologie di sorgenti (-mm, per esempio),
417quilt è il miglior strumento per svolgere il lavoro.
418
419
420Liste di discussione
421--------------------
422
423Una grossa parte del lavoro di sviluppo del Kernel Linux viene svolto tramite
424le liste di discussione.  È difficile essere un membro della comunità
425pienamente coinvolto se non si partecipa almeno ad una lista da qualche
426parte.  Ma, le liste di discussione di Linux rappresentano un potenziale
427problema per gli sviluppatori, che rischiano di venir sepolti da un mare di
428email, restare incagliati nelle convenzioni in vigore nelle liste Linux,
429o entrambi.
430
431Molte delle liste di discussione del Kernel girano su vger.kernel.org;
432l'elenco principale lo si trova sul sito:
433
434	http://vger.kernel.org/vger-lists.html
435
436Esistono liste gestite altrove; un certo numero di queste sono in
437lists.redhat.com.
438
439La lista di discussione principale per lo sviluppo del kernel è, ovviamente,
440linux-kernel.  Questa lista è un luogo ostile dove trovarsi; i volumi possono
441raggiungere i 500 messaggi al giorno, la quantità di "rumore" è elevata,
442la conversazione può essere strettamente tecnica e i partecipanti non sono
443sempre preoccupati di mostrare un alto livello di educazione.  Ma non esiste
444altro luogo dove la comunità di sviluppo del kernel si unisce per intero;
445gli sviluppatori che evitano tale lista si perderanno informazioni importanti.
446
447Ci sono alcuni consigli che possono essere utili per sopravvivere a
448linux-kernel:
449
450- Tenete la lista in una cartella separata, piuttosto che inserirla nella
451  casella di posta principale.  Così da essere in grado di ignorare il flusso
452  di mail per un certo periodo di tempo.
453
454- Non cercate di seguire ogni conversazione - nessuno lo fa.  È importante
455  filtrare solo gli argomenti d'interesse (sebbene va notato che le
456  conversazioni di lungo periodo possono deviare dall'argomento originario
457  senza cambiare il titolo della mail) e le persone che stanno partecipando.
458
459- Non alimentate i troll. Se qualcuno cerca di creare nervosismo, ignoratelo.
460
461- Quando rispondete ad una mail linux-kernel (o ad altre liste) mantenete
462  tutti i Cc:.  In assenza di importanti motivazioni (come una richiesta
463  esplicita), non dovreste mai togliere destinatari.  Assicuratevi sempre che
464  la persona alla quale state rispondendo sia presente nella lista Cc. Questa
465  usanza fa si che divenga inutile chiedere esplicitamente di essere inseriti
466  in copia nel rispondere al vostro messaggio.
467
468- Cercate nell'archivio della lista (e nella rete nella sua totalità) prima
469  di far domande.  Molti sviluppatori possono divenire impazienti con le
470  persone che chiaramente non hanno svolto i propri compiti a casa.
471
472- Evitate il *top-posting* (cioè la pratica di mettere la vostra risposta sopra
473  alla frase alla quale state rispondendo).  Ciò renderebbe la vostra risposta
474  difficile da leggere e genera scarsa impressione.
475
476- Chiedete nella lista di discussione corretta.  Linux-kernel può essere un
477  punto di incontro generale, ma non è il miglior posto dove trovare
478  sviluppatori da tutti i sottosistemi.
479
480Infine, la ricerca della corretta lista di discussione è uno degli errori più
481comuni per gli sviluppatori principianti.  Qualcuno che pone una domanda
482relativa alla rete su linux-kernel riceverà quasi certamente il suggerimento
483di chiedere sulla lista netdev, che è la lista frequentata dagli sviluppatori
484di rete.  Ci sono poi altre liste per i sottosistemi SCSI, video4linux, IDE,
485filesystem, etc.  Il miglior posto dove cercare una lista di discussione è il
486file MAINTAINERS che si trova nei sorgenti del kernel.
487
488Iniziare con lo sviluppo del Kernel
489-----------------------------------
490
491Sono comuni le domande sul come iniziare con lo sviluppo del kernel - sia da
492singole persone che da aziende.  Altrettanto comuni sono i passi falsi che
493rendono l'inizio di tale relazione più difficile di quello che dovrebbe essere.
494
495Le aziende spesso cercano di assumere sviluppatori noti per creare un gruppo
496di sviluppo iniziale.  Questo, in effetti, può essere una tecnica efficace.
497Ma risulta anche essere dispendiosa e non va ad accrescere il bacino di
498sviluppatori kernel con esperienza.  È possibile anche "portare a casa"
499sviluppatori per accelerare lo sviluppo del kernel, dando comunque
500all'investimento un po' di tempo.  Prendersi questo tempo può fornire
501al datore di lavoro un gruppo di sviluppatori che comprendono sia il kernel
502che l'azienda stessa, e che possono supportare la formazione di altre persone.
503Nel medio periodo, questa è spesso uno delle soluzioni più proficue.
504
505I singoli sviluppatori sono spesso, comprensibilmente, una perdita come punto
506di partenza.  Iniziare con un grande progetto può rivelarsi intimidatorio;
507spesso all'inizio si vuole solo verificare il terreno con qualcosa di piccolo.
508Questa è una delle motivazioni per le quali molti sviluppatori saltano alla
509creazione di patch che vanno a sistemare errori di battitura o
510problematiche minori legate allo stile del codice.  Sfortunatamente, tali
511patch creano un certo livello di rumore che distrae l'intera comunità di
512sviluppo, quindi, sempre di più, esse vengono degradate.  I nuovi sviluppatori
513che desiderano presentarsi alla comunità non riceveranno l'accoglienza
514che vorrebbero con questi mezzi.
515
516Andrew Morton da questo consiglio agli aspiranti sviluppatori kernel
517
518::
519
520     Il primo progetto per un neofita del kernel dovrebbe essere
521     sicuramente quello di "assicurarsi che il kernel funzioni alla
522     perfezione sempre e su tutte le macchine sulle quali potete stendere
523     la vostra mano".  Solitamente il modo per fare ciò è quello di
524     collaborare con gli altri nel sistemare le cose (questo richiede
525     persistenza!) ma va bene - è parte dello sviluppo kernel.
526
527(http://lwn.net/Articles/283982/).
528
529In assenza di problemi ovvi da risolvere, si consiglia agli sviluppatori
530di consultare, in generale, la lista di regressioni e di bachi aperti.
531Non c'è mai carenza di problematiche bisognose di essere sistemate;
532accollandosi tali questioni gli sviluppatori accumuleranno esperienza con
533la procedura, ed allo stesso tempo, aumenteranno la loro rispettabilità
534all'interno della comunità di sviluppo.
535