1 .. include:: ../disclaimer-ita.rst
3 :Original: :ref:`Documentation/process/2.Process.rst <development_process>`
4 :Translator: Alessia Mantegazza <amantegazza@vaga.pv.it>
6 .. _it_development_process:
8 Come funziona il processo di sviluppo
9 =====================================
11 Lo sviluppo del Kernel agli inizi degli anno '90 era abbastanza libero, con
12 un numero di utenti e sviluppatori relativamente basso. Con una base
13 di milioni di utenti e con 2000 sviluppatori coinvolti nel giro di un anno,
14 il kernel da allora ha messo in atto un certo numero di procedure per rendere
15 lo sviluppo più agevole. È richiesta una solida conoscenza di come tale
16 processo si svolge per poter esserne parte attiva.
21 Gli sviluppatori kernel utilizzano un calendario di rilascio generico, dove
22 ogni due o tre mesi viene effettuata un rilascio importante del kernel.
23 I rilasci più recenti sono stati:
25 ====== =================
28 4.13 Settembre 3, 2017
29 4.14 Novembre 12, 2017
32 ====== =================
34 Ciascun rilascio 4.x è un importante rilascio del kernel con nuove
35 funzionalità, modifiche interne dell'API, e molto altro. Un tipico
36 rilascio 4.x contiene quasi 13,000 gruppi di modifiche con ulteriori
37 modifiche a parecchie migliaia di linee di codice. La 4.x. è pertanto la
38 linea di confine nello sviluppo del kernel Linux; il kernel utilizza un sistema
39 di sviluppo continuo che integra costantemente nuove importanti modifiche.
41 Viene seguita una disciplina abbastanza lineare per l'inclusione delle
42 patch di ogni rilascio. All'inizio di ogni ciclo di sviluppo, la
43 "finestra di inclusione" viene dichiarata aperta. In quel momento il codice
44 ritenuto sufficientemente stabile(e che è accettato dalla comunità di sviluppo)
45 viene incluso nel ramo principale del kernel. La maggior parte delle
46 patch per un nuovo ciclo di sviluppo (e tutte le più importanti modifiche)
47 saranno inserite durante questo periodo, ad un ritmo che si attesta sulle
48 1000 modifiche ("patch" o "gruppo di modifiche") al giorno.
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
52 raccolti e, verificati in anticipo. Il funzionamento di tale procedimento
53 verrà descritto dettagliatamente più avanti).
55 La finestra di inclusione resta attiva approssimativamente per due settimane.
56 Al termine di questo periodo, Linus Torvald dichiarerà che la finestra è
57 chiusa e rilascerà il primo degli "rc" del kernel.
58 Per il kernel che è destinato ad essere 2.6.40, per esempio, il rilascio
59 che emerge al termine della finestra d'inclusione si chiamerà 2.6.40-rc1.
60 Questo rilascio indica che il momento di aggiungere nuovi componenti è
61 passato, e che è iniziato il periodo di stabilizzazione del prossimo kernel.
63 Nelle successive sei/dieci settimane, potranno essere sottoposte solo modifiche
64 che vanno a risolvere delle problematiche. Occasionalmente potrà essere
65 consentita una modifica più consistente, ma tali occasioni sono rare.
66 Gli sviluppatori che tenteranno di aggiungere nuovi elementi al di fuori della
67 finestra di inclusione, tendenzialmente, riceveranno un accoglienza poco
68 amichevole. Come regola generale: se vi perdete la finestra di inclusione per
69 un dato componente, la cosa migliore da fare è aspettare il ciclo di sviluppo
70 successivo (un'eccezione può essere fatta per i driver per hardware non
71 supportati in precedenza; se toccano codice non facente parte di quello
72 attuale, che non causino regressioni e che potrebbero essere aggiunti in
73 sicurezza in un qualsiasi momento)
75 Mentre le correzioni si aprono la loro strada all'interno del ramo principale,
76 il ritmo delle modifiche rallenta col tempo. Linus rilascia un nuovo
77 kernel -rc circa una volta alla settimana; e ne usciranno circa 6 o 9 prima
78 che il kernel venga considerato sufficientemente stabile e che il rilascio
79 finale 2.6.x venga fatto. A quel punto tutto il processo ricomincerà.
81 Esempio: ecco com'è andato il ciclo di sviluppo della versione 4.16
82 (tutte le date si collocano nel 2018)
85 ============== =======================================
86 Gennaio 28 4.15 rilascio stabile
87 Febbraio 11 4.16-rc1, finestra di inclusione chiusa
94 Aprile 1 4.17 rilascio stabile
95 ============== =======================================
97 In che modo gli sviluppatori decidono quando chiudere il ciclo di sviluppo e
98 creare quindi una rilascio stabile? Un metro valido è il numero di regressioni
99 rilevate nel precedente rilascio. Nessun baco è il benvenuto, ma quelli che
100 procurano problemi su sistemi che hanno funzionato in passato sono considerati
101 particolarmente seri. Per questa ragione, le modifiche che portano ad una
102 regressione sono viste sfavorevolmente e verranno quasi sicuramente annullate
103 durante il periodo di stabilizzazione.
105 L'obiettivo degli sviluppatori è quello di aggiustare tutte le regressioni
106 conosciute prima che avvenga il rilascio stabile. Nel mondo reale, questo
107 tipo di perfezione difficilmente viene raggiunta; esistono troppe variabili
108 in un progetto di questa portata. Arriva un punto dove ritardare il rilascio
109 finale peggiora la situazione; la quantità di modifiche in attesa della
110 prossima finestra di inclusione crescerà enormemente, creando ancor più
111 regressioni al giro successivo. Quindi molti kernel 4.x escono con una
112 manciata di regressioni delle quali, si spera, nessuna è grave.
114 Una volta che un rilascio stabile è fatto, il suo costante mantenimento è
115 affidato al "squadra stabilità", attualmente composta da Greg Kroah-Hartman.
116 Questa squadra rilascia occasionalmente degli aggiornamenti relativi al
117 rilascio stabile usando la numerazione 4.x.y. Per essere presa in
118 considerazione per un rilascio d'aggiornamento, una modifica deve:
119 (1) correggere un baco importante (2) essere già inserita nel ramo principale
120 per il prossimo sviluppo del kernel. Solitamente, passato il loro rilascio
121 iniziale, i kernel ricevono aggiornamenti per più di un ciclo di sviluppo.
122 Quindi, per esempio, la storia del kernel 4.13 appare così:
124 ============== ===============================
125 Settembre 3 4.13 rilascio stabile
133 ============== ===============================
135 La 4.13.16 fu l'aggiornamento finale per la versione 4.13.
137 Alcuni kernel sono destinati ad essere kernel a "lungo termine"; questi
138 riceveranno assistenza per un lungo periodo di tempo. Al momento in cui
139 scriviamo, i manutentori dei kernel stabili a lungo termine sono:
141 ====== ====================== ==========================================
142 3.16 Ben Hutchings (kernel stabile molto più a lungo termine)
144 4.4 Greg Kroah-Hartman (kernel stabile molto più a lungo termine)
145 4.9 Greg Kroah-Hartman
146 4.14 Greg Kroah-Hartman
147 ====== ====================== ==========================================
150 Questa selezione di kernel di lungo periodo sono puramente dovuti ai loro
151 manutentori, alla loro necessità e al tempo per tenere aggiornate proprio
152 quelle versioni. Non ci sono altri kernel a lungo termine in programma per
153 alcun rilascio in arrivo.
155 Il ciclo di vita di una patch
156 -----------------------------
158 Le patch non passano direttamente dalla tastiera dello sviluppatori
159 al ramo principale del kernel. Esiste, invece, una procedura disegnata
160 per assicurare che ogni patch sia di buona qualità e desiderata nel
161 ramo principale. Questo processo avviene velocemente per le correzioni
162 meno importanti, o, nel caso di patch ampie e controverse, va avanti per anni.
163 Per uno sviluppatore la maggior frustrazione viene dalla mancanza di
164 comprensione di questo processo o dai tentativi di aggirarlo.
166 Nella speranza di ridurre questa frustrazione, questo documento spiegherà
167 come una patch viene inserita nel kernel. Ciò che segue è un'introduzione
168 che descrive il processo ideale. Approfondimenti verranno invece trattati
171 Una patch attraversa, generalmente, le seguenti fasi:
173 - Progetto. In questa fase sono stabilite quelli che sono i requisiti
174 della modifica - e come verranno soddisfatti. Il lavoro di progettazione
175 viene spesso svolto senza coinvolgere la comunità, ma è meglio renderlo
176 il più aperto possibile; questo può far risparmiare molto tempo evitando
177 eventuali riprogettazioni successive.
179 - Prima revisione. Le patch vengono pubblicate sulle liste di discussione
180 interessate, e gli sviluppatori in quella lista risponderanno coi loro
181 commenti. Se si svolge correttamente, questo procedimento potrebbe far
182 emergere problemi rilevanti in una patch.
184 - Revisione più ampia. Quando la patch è quasi pronta per essere inserita
185 nel ramo principale, un manutentore importante del sottosistema dovrebbe
186 accettarla - anche se, questa accettazione non è una garanzia che la
187 patch arriverà nel ramo principale. La patch sarà visibile nei sorgenti
188 del sottosistema in questione e nei sorgenti -next (descritti sotto).
189 Quando il processo va a buon fine, questo passo porta ad una revisione
190 più estesa della patch e alla scoperta di problemi d'integrazione
191 con il lavoro altrui.
193 - Per favore, tenete da conto che la maggior parte dei manutentori ha
194 anche un lavoro quotidiano, quindi integrare le vostre patch potrebbe
195 non essere la loro priorità più alta. Se una vostra patch riceve
196 dei suggerimenti su dei cambiamenti necessari, dovreste applicare
197 quei cambiamenti o giustificare perché non sono necessari. Se la vostra
198 patch non riceve alcuna critica ma non è stata integrata dal
199 manutentore del driver o sottosistema, allora dovreste continuare con
200 i necessari aggiornamenti per mantenere la patch aggiornata al kernel
201 più recente cosicché questa possa integrarsi senza problemi; continuate
202 ad inviare gli aggiornamenti per essere revisionati e integrati.
204 - Inclusione nel ramo principale. Eventualmente, una buona patch verrà
205 inserita all'interno nel repositorio principale, gestito da
206 Linus Torvalds. In questa fase potrebbero emergere nuovi problemi e/o
207 commenti; è importante che lo sviluppatore sia collaborativo e che sistemi
208 ogni questione che possa emergere.
210 - Rilascio stabile. Ora, il numero di utilizzatori che sono potenzialmente
211 toccati dalla patch è aumentato, quindi, ancora una volta, potrebbero
212 emergere nuovi problemi.
214 - Manutenzione di lungo periodo. Nonostante sia possibile che uno sviluppatore
215 si dimentichi del codice dopo la sua integrazione, questo comportamento
216 lascia una brutta impressione nella comunità di sviluppo. Integrare il
217 codice elimina alcuni degli oneri facenti parte della manutenzione, in
218 particolare, sistemerà le problematiche causate dalle modifiche all'API.
219 Ma lo sviluppatore originario dovrebbe continuare ad assumersi la
220 responsabilità per il codice se quest'ultimo continua ad essere utile
223 Uno dei più grandi errori fatti dagli sviluppatori kernel (o dai loro datori
224 di lavoro) è quello di cercare di ridurre tutta la procedura ad una singola
225 "integrazione nel remo principale". Questo approccio inevitabilmente conduce
226 a una condizione di frustrazione per tutti coloro che sono coinvolti.
228 Come le modifiche finiscono nel Kernel
229 --------------------------------------
231 Esiste una sola persona che può inserire le patch nel repositorio principale
232 del kernel: Linus Torvalds. Ma, di tutte le 9500 patch che entrarono nella
233 versione 2.6.38 del kernel, solo 112 (circa l'1,3%) furono scelte direttamente
234 da Linus in persona. Il progetto del kernel è cresciuto fino a raggiungere
235 una dimensione tale per cui un singolo sviluppatore non può controllare e
236 selezionare indipendentemente ogni modifica senza essere supportato.
237 La via scelta dagli sviluppatori per indirizzare tale crescita è stata quella
238 di utilizzare un sistema di "sottotenenti" basato sulla fiducia.
240 Il codice base del kernel è spezzato in una serie si sottosistemi: rete,
241 supporto per specifiche architetture, gestione della memoria, video e
242 strumenti, etc. Molti sottosistemi hanno un manutentore designato: ovvero uno
243 sviluppatore che ha piena responsabilità di tutto il codice presente in quel
244 sottosistema. Tali manutentori di sottosistema sono i guardiani
245 (in un certo senso) della parte di kernel che gestiscono; sono coloro che
246 (solitamente) accetteranno una patch per l'inclusione nel ramo principale
249 I manutentori di sottosistema gestiscono ciascuno la propria parte dei sorgenti
250 del kernel, utilizzando abitualmente (ma certamente non sempre) git.
251 Strumenti come git (e affini come quilt o mercurial) permettono ai manutentori
252 di stilare una lista delle patch, includendo informazioni sull'autore ed
253 altri metadati. In ogni momento, il manutentore può individuare quale patch
254 nel sua repositorio non si trova nel ramo principale.
256 Quando la "finestra di integrazione" si apre, i manutentori di alto livello
257 chiederanno a Linus di "prendere" dai loro repositori le modifiche che hanno
258 selezionato per l'inclusione. Se Linus acconsente, il flusso di patch si
259 convoglierà nel repositorio di quest ultimo, divenendo così parte del ramo
260 principale del kernel. La quantità d'attenzione che Linus presta alle
261 singole patch ricevute durante l'operazione di integrazione varia.
262 È chiaro che, qualche volta, guardi più attentamente. Ma, come regola
263 generale, Linus confida nel fatto che i manutentori di sottosistema non
264 selezionino pessime patch.
266 I manutentori di sottosistemi, a turno, possono "prendere" patch
267 provenienti da altri manutentori. Per esempio, i sorgenti per la rete rete
268 sono costruiti da modifiche che si sono accumulate inizialmente nei sorgenti
269 dedicati ai driver per dispositivi di rete, rete senza fili, ecc. Tale
270 catena di repositori può essere più o meno lunga, benché raramente ecceda
271 i due o tre collegamenti. Questo processo è conosciuto come
272 "la catena della fiducia", perché ogni manutentore all'interno della
273 catena si fida di coloro che gestiscono i livelli più bassi.
275 Chiaramente, in un sistema come questo, l'inserimento delle patch all'interno
276 del kernel si basa sul trovare il manutentore giusto. Di norma, inviare
277 patch direttamente a Linus non è la via giusta.
283 La catena di sottosistemi guida il flusso di patch all'interno del kernel,
284 ma solleva anche un interessante quesito: se qualcuno volesse vedere tutte le
285 patch pronte per la prossima finestra di integrazione?
286 Gli sviluppatori si interesseranno alle patch in sospeso per verificare
287 che non ci siano altri conflitti di cui preoccuparsi; una modifica che, per
288 esempio, cambia il prototipo di una funzione fondamentale del kernel andrà in
289 conflitto con qualsiasi altra modifica che utilizzi la vecchia versione di
290 quella funzione. Revisori e tester vogliono invece avere accesso alle
291 modifiche nella loro totalità prima che approdino nel ramo principale del
292 kernel. Uno potrebbe prendere le patch provenienti da tutti i sottosistemi
293 d'interesse, ma questo sarebbe un lavoro enorme e fallace.
295 La risposta ci viene sotto forma di sorgenti -next, dove i sottosistemi sono
296 raccolti per essere testati e controllati. Il più vecchio di questi sorgenti,
297 gestito da Andrew Morton, è chiamato "-mm" (memory management, che è l'inizio
298 di tutto). L'-mm integra patch proveniente da una lunga lista di sottosistemi;
299 e ha, inoltre, alcune patch destinate al supporto del debugging.
301 Oltre a questo, -mm contiene una raccolta significativa di patch che sono
302 state selezionate da Andrew direttamente. Queste patch potrebbero essere
303 state inviate in una lista di discussione, o possono essere applicate ad una
304 parte del kernel per la quale non esiste un sottosistema dedicato.
305 Di conseguenza, -mm opera come una specie di sottosistema "ultima spiaggia";
306 se per una patch non esiste una via chiara per entrare nel ramo principale,
307 allora è probabile che finirà in -mm. Le patch passate per -mm
308 eventualmente finiranno nel sottosistema più appropriato o saranno inviate
309 direttamente a Linus. In un tipico ciclo di sviluppo, circa il 5-10% delle
310 patch andrà nel ramo principale attraverso -mm.
312 La patch -mm correnti sono disponibili nella cartella "mmotm" (-mm of
313 the moment) all'indirizzo:
315 http://www.ozlabs.org/~akpm/mmotm/
317 È molto probabile che l'uso dei sorgenti MMOTM diventi un'esperienza
318 frustrante; ci sono buone probabilità che non compili nemmeno.
320 I sorgenti principali per il prossimo ciclo d'integrazione delle patch
321 è linux-next, gestito da Stephen Rothwell. I sorgenti linux-next sono, per
322 definizione, un'istantanea di come dovrà apparire il ramo principale dopo che
323 la prossima finestra di inclusione si chiuderà. I linux-next sono annunciati
324 sulla lista di discussione linux-kernel e linux-next nel momento in cui
325 vengono assemblati; e possono essere scaricate da:
327 http://www.kernel.org/pub/linux/kernel/next/
329 Linux-next è divenuto parte integrante del processo di sviluppo del kernel;
330 tutte le patch incorporate durante una finestra di integrazione dovrebbero
331 aver trovato la propria strada in linux-next, a volte anche prima dell'apertura
332 della finestra di integrazione.
335 Sorgenti in preparazione
336 ------------------------
338 Nei sorgenti del kernel esiste la cartella drivers/staging/, dove risiedono
339 molte sotto-cartelle per i driver o i filesystem che stanno per essere aggiunti
340 al kernel. Questi restano nella cartella drivers/staging fintanto che avranno
341 bisogno di maggior lavoro; una volta completato, possono essere spostate
342 all'interno del kernel nel posto più appropriato. Questo è il modo di tener
343 traccia dei driver che non sono ancora in linea con gli standard di codifica
344 o qualità, ma che le persone potrebbero voler usare ugualmente e tracciarne
347 Greg Kroah-Hartman attualmente gestisce i sorgenti in preparazione. I driver
348 che non sono completamente pronti vengono inviati a lui, e ciascun driver avrà
349 la propria sotto-cartella in drivers/staging/. Assieme ai file sorgenti
350 dei driver, dovrebbe essere presente nella stessa cartella anche un file TODO.
351 Il file TODO elenca il lavoro ancora da fare su questi driver per poter essere
352 accettati nel kernel, e indica anche la lista di persone da inserire in copia
353 conoscenza per ogni modifica fatta. Le regole attuali richiedono che i
354 driver debbano, come minimo, compilare adeguatamente.
356 La *preparazione* può essere una via relativamente facile per inserire nuovi
357 driver all'interno del ramo principale, dove, con un po' di fortuna, saranno
358 notati da altri sviluppatori e migliorati velocemente. Entrare nella fase
359 di preparazione non è però la fine della storia, infatti, il codice che si
360 trova nella cartella staging che non mostra regolari progressi potrebbe
361 essere rimosso. Le distribuzioni, inoltre, tendono a dimostrarsi relativamente
362 riluttanti nell'attivare driver in preparazione. Quindi lo preparazione è,
363 nel migliore dei casi, una tappa sulla strada verso il divenire un driver
370 Come è possibile notare dal testo sopra, il processo di sviluppo del kernel
371 dipende pesantemente dalla capacità di guidare la raccolta di patch in
372 diverse direzioni. L'intera cosa non funzionerebbe se non venisse svolta
373 con l'uso di strumenti appropriati e potenti. Spiegare l'uso di tali
374 strumenti non è lo scopo di questo documento, ma c'è spazio per alcuni
377 In assoluto, nella comunità del kernel, predomina l'uso di git come sistema
378 di gestione dei sorgenti. Git è una delle diverse tipologie di sistemi
379 distribuiti di controllo versione che sono stati sviluppati nella comunità
380 del software libero. Esso è calibrato per lo sviluppo del kernel, e si
381 comporta abbastanza bene quando ha a che fare con repositori grandi e con un
382 vasto numero di patch. Git ha inoltre la reputazione di essere difficile
383 da imparare e utilizzare, benché stia migliorando. Agli sviluppatori
384 del kernel viene richiesta un po' di familiarità con git; anche se non lo
385 utilizzano per il proprio lavoro, hanno bisogno di git per tenersi al passo
386 con il lavoro degli altri sviluppatori (e con il ramo principale).
388 Git è ora compreso in quasi tutte le distribuzioni Linux. Esiste una sito che
393 Qui troverete i riferimenti alla documentazione e alle guide passo-passo.
395 Tra gli sviluppatori Kernel che non usano git, la scelta alternativa più
396 popolare è quasi sicuramente Mercurial:
398 http://www.selenic.com/mercurial/
400 Mercurial condivide diverse caratteristiche con git, ma fornisce
401 un'interfaccia che potrebbe risultare più semplice da utilizzare.
403 L'altro strumento che vale la pena conoscere è Quilt:
405 http://savannah.nongnu.org/projects/quilt/
408 Quilt è un sistema di gestione delle patch, piuttosto che un sistema
409 di gestione dei sorgenti. Non mantiene uno storico degli eventi; ma piuttosto
410 è orientato verso il tracciamento di uno specifico insieme di modifiche
411 rispetto ad un codice in evoluzione. Molti dei più grandi manutentori di
412 sottosistema utilizzano quilt per gestire le patch che dovrebbero essere
413 integrate. Per la gestione di certe tipologie di sorgenti (-mm, per esempio),
414 quilt è il miglior strumento per svolgere il lavoro.
420 Una grossa parte del lavoro di sviluppo del Kernel Linux viene svolto tramite
421 le liste di discussione. È difficile essere un membro della comunità
422 pienamente coinvolto se non si partecipa almeno ad una lista da qualche
423 parte. Ma, le liste di discussione di Linux rappresentano un potenziale
424 problema per gli sviluppatori, che rischiano di venir sepolti da un mare di
425 email, restare incagliati nelle convenzioni in vigore nelle liste Linux,
428 Molte delle liste di discussione del Kernel girano su vger.kernel.org;
429 l'elenco principale lo si trova sul sito:
431 http://vger.kernel.org/vger-lists.html
433 Esistono liste gestite altrove; un certo numero di queste sono in
436 La lista di discussione principale per lo sviluppo del kernel è, ovviamente,
437 linux-kernel. Questa lista è un luogo ostile dove trovarsi; i volumi possono
438 raggiungere i 500 messaggi al giorno, la quantità di "rumore" è elevata,
439 la conversazione può essere strettamente tecnica e i partecipanti non sono
440 sempre preoccupati di mostrare un alto livello di educazione. Ma non esiste
441 altro luogo dove la comunità di sviluppo del kernel si unisce per intero;
442 gli sviluppatori che evitano tale lista si perderanno informazioni importanti.
444 Ci sono alcuni consigli che possono essere utili per sopravvivere a
447 - Tenete la lista in una cartella separata, piuttosto che inserirla nella
448 casella di posta principale. Così da essere in grado di ignorare il flusso
449 di mail per un certo periodo di tempo.
451 - Non cercate di seguire ogni conversazione - nessuno lo fa. È importante
452 filtrare solo gli argomenti d'interesse (sebbene va notato che le
453 conversazioni di lungo periodo possono deviare dall'argomento originario
454 senza cambiare il titolo della mail) e le persone che stanno partecipando.
456 - Non alimentate i troll. Se qualcuno cerca di creare nervosismo, ignoratelo.
458 - Quando rispondete ad una mail linux-kernel (o ad altre liste) mantenete
459 tutti i Cc:. In assenza di importanti motivazioni (come una richiesta
460 esplicita), non dovreste mai togliere destinatari. Assicuratevi sempre che
461 la persona alla quale state rispondendo sia presente nella lista Cc. Questa
462 usanza fa si che divenga inutile chiedere esplicitamente di essere inseriti
463 in copia nel rispondere al vostro messaggio.
465 - Cercate nell'archivio della lista (e nella rete nella sua totalità) prima
466 di far domande. Molti sviluppatori possono divenire impazienti con le
467 persone che chiaramente non hanno svolto i propri compiti a casa.
469 - Evitate il *top-posting* (cioè la pratica di mettere la vostra risposta sopra
470 alla frase alla quale state rispondendo). Ciò renderebbe la vostra risposta
471 difficile da leggere e genera scarsa impressione.
473 - Chiedete nella lista di discussione corretta. Linux-kernel può essere un
474 punto di incontro generale, ma non è il miglior posto dove trovare
475 sviluppatori da tutti i sottosistemi.
477 Infine, la ricerca della corretta lista di discussione è uno degli errori più
478 comuni per gli sviluppatori principianti. Qualcuno che pone una domanda
479 relativa alla rete su linux-kernel riceverà quasi certamente il suggerimento
480 di chiedere sulla lista netdev, che è la lista frequentata dagli sviluppatori
481 di rete. Ci sono poi altre liste per i sottosistemi SCSI, video4linux, IDE,
482 filesystem, etc. Il miglior posto dove cercare una lista di discussione è il
483 file MAINTAINERS che si trova nei sorgenti del kernel.
485 Iniziare con lo sviluppo del Kernel
486 -----------------------------------
488 Sono comuni le domande sul come iniziare con lo sviluppo del kernel - sia da
489 singole persone che da aziende. Altrettanto comuni sono i passi falsi che
490 rendono l'inizio di tale relazione più difficile di quello che dovrebbe essere.
492 Le aziende spesso cercano di assumere sviluppatori noti per creare un gruppo
493 di sviluppo iniziale. Questo, in effetti, può essere una tecnica efficace.
494 Ma risulta anche essere dispendiosa e non va ad accrescere il bacino di
495 sviluppatori kernel con esperienza. È possibile anche "portare a casa"
496 sviluppatori per accelerare lo sviluppo del kernel, dando comunque
497 all'investimento un po' di tempo. Prendersi questo tempo può fornire
498 al datore di lavoro un gruppo di sviluppatori che comprendono sia il kernel
499 che l'azienda stessa, e che possono supportare la formazione di altre persone.
500 Nel medio periodo, questa è spesso uno delle soluzioni più proficue.
502 I singoli sviluppatori sono spesso, comprensibilmente, una perdita come punto
503 di partenza. Iniziare con un grande progetto può rivelarsi intimidatorio;
504 spesso all'inizio si vuole solo verificare il terreno con qualcosa di piccolo.
505 Questa è una delle motivazioni per le quali molti sviluppatori saltano alla
506 creazione di patch che vanno a sistemare errori di battitura o
507 problematiche minori legate allo stile del codice. Sfortunatamente, tali
508 patch creano un certo livello di rumore che distrae l'intera comunità di
509 sviluppo, quindi, sempre di più, esse vengono degradate. I nuovi sviluppatori
510 che desiderano presentarsi alla comunità non riceveranno l'accoglienza
511 che vorrebbero con questi mezzi.
513 Andrew Morton da questo consiglio agli aspiranti sviluppatori kernel
517 Il primo progetto per un neofita del kernel dovrebbe essere
518 sicuramente quello di "assicurarsi che il kernel funzioni alla
519 perfezione sempre e su tutte le macchine sulle quali potete stendere
520 la vostra mano". Solitamente il modo per fare ciò è quello di
521 collaborare con gli altri nel sistemare le cose (questo richiede
522 persistenza!) ma va bene - è parte dello sviluppo kernel.
524 (http://lwn.net/Articles/283982/).
526 In assenza di problemi ovvi da risolvere, si consiglia agli sviluppatori
527 di consultare, in generale, la lista di regressioni e di bachi aperti.
528 Non c'è mai carenza di problematiche bisognose di essere sistemate;
529 accollandosi tali questioni gli sviluppatori accumuleranno esperienza con
530 la procedura, ed allo stesso tempo, aumenteranno la loro rispettabilità
531 all'interno della comunità di sviluppo.
git.samba.org / sfrench / cifs-2.6.git / blob