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 ====== =================
29 5.3 15 settembre, 2019
32 ====== =================
34 Ciascun rilascio 5.x è un importante rilascio del kernel con nuove
35 funzionalità, modifiche interne dell'API, e molto altro. Un tipico
36 rilascio contiene quasi 13,000 gruppi di modifiche con ulteriori
37 modifiche a parecchie migliaia di linee di codice. La 5.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 5.6, per esempio, il rilascio
59 che emerge al termine della finestra d'inclusione si chiamerà 5.6-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 venga fatto. A quel punto tutto il processo ricomincerà.
81 Esempio: ecco com'è andato il ciclo di sviluppo della versione 5.4
82 (tutte le date si collocano nel 2018)
85 ============== =======================================
86 15 settembre 5.3 rilascio stabile
87 30 settembre 5.4-rc1, finestra di inclusione chiusa
95 24 novembre 5.4 rilascio stabile
96 ============== =======================================
98 In che modo gli sviluppatori decidono quando chiudere il ciclo di sviluppo e
99 creare quindi una rilascio stabile? Un metro valido è il numero di regressioni
100 rilevate nel precedente rilascio. Nessun baco è il benvenuto, ma quelli che
101 procurano problemi su sistemi che hanno funzionato in passato sono considerati
102 particolarmente seri. Per questa ragione, le modifiche che portano ad una
103 regressione sono viste sfavorevolmente e verranno quasi sicuramente annullate
104 durante il periodo di stabilizzazione.
106 L'obiettivo degli sviluppatori è quello di aggiustare tutte le regressioni
107 conosciute prima che avvenga il rilascio stabile. Nel mondo reale, questo
108 tipo di perfezione difficilmente viene raggiunta; esistono troppe variabili
109 in un progetto di questa portata. Arriva un punto dove ritardare il rilascio
110 finale peggiora la situazione; la quantità di modifiche in attesa della
111 prossima finestra di inclusione crescerà enormemente, creando ancor più
112 regressioni al giro successivo. Quindi molti kernel 5.x escono con una
113 manciata di regressioni delle quali, si spera, nessuna è grave.
115 Una volta che un rilascio stabile è fatto, il suo costante mantenimento è
116 affidato al "squadra stabilità", attualmente composta da Greg Kroah-Hartman.
117 Questa squadra rilascia occasionalmente degli aggiornamenti relativi al
118 rilascio stabile usando la numerazione 5.x.y. Per essere presa in
119 considerazione per un rilascio d'aggiornamento, una modifica deve:
120 (1) correggere un baco importante (2) essere già inserita nel ramo principale
121 per il prossimo sviluppo del kernel. Solitamente, passato il loro rilascio
122 iniziale, i kernel ricevono aggiornamenti per più di un ciclo di sviluppo.
123 Quindi, per esempio, la storia del kernel 5.2 appare così (anno 2019):
125 ============== ===============================
126 7 luglio 5.2 rilascio stabile
134 ============== ===============================
136 La 5.2.21 fu l'aggiornamento finale per la versione 5.2.
138 Alcuni kernel sono destinati ad essere kernel a "lungo termine"; questi
139 riceveranno assistenza per un lungo periodo di tempo. Al momento in cui
140 scriviamo, i manutentori dei kernel stabili a lungo termine sono:
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 ====== ================================ ==========================================
152 Questa selezione di kernel di lungo periodo sono puramente dovuti ai loro
153 manutentori, alla loro necessità e al tempo per tenere aggiornate proprio
154 quelle versioni. Non ci sono altri kernel a lungo termine in programma per
155 alcun rilascio in arrivo.
157 Il ciclo di vita di una patch
158 -----------------------------
160 Le patch non passano direttamente dalla tastiera dello sviluppatori
161 al ramo principale del kernel. Esiste, invece, una procedura disegnata
162 per assicurare che ogni patch sia di buona qualità e desiderata nel
163 ramo principale. Questo processo avviene velocemente per le correzioni
164 meno importanti, o, nel caso di patch ampie e controverse, va avanti per anni.
165 Per uno sviluppatore la maggior frustrazione viene dalla mancanza di
166 comprensione di questo processo o dai tentativi di aggirarlo.
168 Nella speranza di ridurre questa frustrazione, questo documento spiegherà
169 come una patch viene inserita nel kernel. Ciò che segue è un'introduzione
170 che descrive il processo ideale. Approfondimenti verranno invece trattati
173 Una patch attraversa, generalmente, le seguenti fasi:
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.
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.
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.
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.
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.
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.
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
225 Uno dei più grandi errori fatti dagli sviluppatori kernel (o dai loro datori
226 di lavoro) è quello di cercare di ridurre tutta la procedura ad una singola
227 "integrazione nel remo principale". Questo approccio inevitabilmente conduce
228 a una condizione di frustrazione per tutti coloro che sono coinvolti.
230 Come le modifiche finiscono nel Kernel
231 --------------------------------------
233 Esiste una sola persona che può inserire le patch nel repositorio principale
234 del kernel: Linus Torvalds. Ma, per esempio, di tutte le 9500 patch
235 che entrarono nella versione 2.6.38 del kernel, solo 112 (circa
236 l'1,3%) furono scelte direttamente da Linus in persona. Il progetto
237 del kernel è cresciuto fino a raggiungere una dimensione tale per cui
238 un singolo sviluppatore non può controllare e selezionare
239 indipendentemente ogni modifica senza essere supportato. La via
240 scelta dagli sviluppatori per indirizzare tale crescita è stata quella
241 di utilizzare un sistema di "sottotenenti" basato sulla fiducia.
243 Il codice base del kernel è spezzato in una serie si sottosistemi: rete,
244 supporto per specifiche architetture, gestione della memoria, video e
245 strumenti, etc. Molti sottosistemi hanno un manutentore designato: ovvero uno
246 sviluppatore che ha piena responsabilità di tutto il codice presente in quel
247 sottosistema. 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
252 I manutentori di sottosistema gestiscono ciascuno la propria parte dei sorgenti
253 del kernel, utilizzando abitualmente (ma certamente non sempre) git.
254 Strumenti come git (e affini come quilt o mercurial) permettono ai manutentori
255 di stilare una lista delle patch, includendo informazioni sull'autore ed
256 altri metadati. In ogni momento, il manutentore può individuare quale patch
257 nel sua repositorio non si trova nel ramo principale.
259 Quando la "finestra di integrazione" si apre, i manutentori di alto livello
260 chiederanno a Linus di "prendere" dai loro repositori le modifiche che hanno
261 selezionato per l'inclusione. Se Linus acconsente, il flusso di patch si
262 convoglierà nel repositorio di quest ultimo, divenendo così parte del ramo
263 principale del kernel. La quantità d'attenzione che Linus presta alle
264 singole patch ricevute durante l'operazione di integrazione varia.
265 È chiaro che, qualche volta, guardi più attentamente. Ma, come regola
266 generale, Linus confida nel fatto che i manutentori di sottosistema non
267 selezionino pessime patch.
269 I manutentori di sottosistemi, a turno, possono "prendere" patch
270 provenienti da altri manutentori. Per esempio, i sorgenti per la rete rete
271 sono costruiti da modifiche che si sono accumulate inizialmente nei sorgenti
272 dedicati ai driver per dispositivi di rete, rete senza fili, ecc. Tale
273 catena di repositori può essere più o meno lunga, benché raramente ecceda
274 i due o tre collegamenti. Questo processo è conosciuto come
275 "la catena della fiducia", perché ogni manutentore all'interno della
276 catena si fida di coloro che gestiscono i livelli più bassi.
278 Chiaramente, in un sistema come questo, l'inserimento delle patch all'interno
279 del kernel si basa sul trovare il manutentore giusto. Di norma, inviare
280 patch direttamente a Linus non è la via giusta.
286 La catena di sottosistemi guida il flusso di patch all'interno del kernel,
287 ma solleva anche un interessante quesito: se qualcuno volesse vedere tutte le
288 patch pronte per la prossima finestra di integrazione?
289 Gli sviluppatori si interesseranno alle patch in sospeso per verificare
290 che non ci siano altri conflitti di cui preoccuparsi; una modifica che, per
291 esempio, cambia il prototipo di una funzione fondamentale del kernel andrà in
292 conflitto con qualsiasi altra modifica che utilizzi la vecchia versione di
293 quella funzione. Revisori e tester vogliono invece avere accesso alle
294 modifiche nella loro totalità prima che approdino nel ramo principale del
295 kernel. Uno potrebbe prendere le patch provenienti da tutti i sottosistemi
296 d'interesse, ma questo sarebbe un lavoro enorme e fallace.
298 La risposta ci viene sotto forma di sorgenti -next, dove i sottosistemi sono
299 raccolti per essere testati e controllati. Il più vecchio di questi sorgenti,
300 gestito da Andrew Morton, è chiamato "-mm" (memory management, che è l'inizio
301 di tutto). L'-mm integra patch proveniente da una lunga lista di sottosistemi;
302 e ha, inoltre, alcune patch destinate al supporto del debugging.
304 Oltre a questo, -mm contiene una raccolta significativa di patch che sono
305 state selezionate da Andrew direttamente. Queste patch potrebbero essere
306 state inviate in una lista di discussione, o possono essere applicate ad una
307 parte del kernel per la quale non esiste un sottosistema dedicato.
308 Di conseguenza, -mm opera come una specie di sottosistema "ultima spiaggia";
309 se per una patch non esiste una via chiara per entrare nel ramo principale,
310 allora è probabile che finirà in -mm. Le patch passate per -mm
311 eventualmente finiranno nel sottosistema più appropriato o saranno inviate
312 direttamente a Linus. In un tipico ciclo di sviluppo, circa il 5-10% delle
313 patch andrà nel ramo principale attraverso -mm.
315 La patch -mm correnti sono disponibili nella cartella "mmotm" (-mm of
316 the moment) all'indirizzo:
318 http://www.ozlabs.org/~akpm/mmotm/
320 È molto probabile che l'uso dei sorgenti MMOTM diventi un'esperienza
321 frustrante; ci sono buone probabilità che non compili nemmeno.
323 I sorgenti principali per il prossimo ciclo d'integrazione delle patch
324 è linux-next, gestito da Stephen Rothwell. I sorgenti linux-next sono, per
325 definizione, un'istantanea di come dovrà apparire il ramo principale dopo che
326 la prossima finestra di inclusione si chiuderà. I linux-next sono annunciati
327 sulla lista di discussione linux-kernel e linux-next nel momento in cui
328 vengono assemblati; e possono essere scaricate da:
330 http://www.kernel.org/pub/linux/kernel/next/
332 Linux-next è divenuto parte integrante del processo di sviluppo del kernel;
333 tutte le patch incorporate durante una finestra di integrazione dovrebbero
334 aver trovato la propria strada in linux-next, a volte anche prima dell'apertura
335 della finestra di integrazione.
338 Sorgenti in preparazione
339 ------------------------
341 Nei sorgenti del kernel esiste la cartella drivers/staging/, dove risiedono
342 molte sotto-cartelle per i driver o i filesystem che stanno per essere aggiunti
343 al kernel. Questi restano nella cartella drivers/staging fintanto che avranno
344 bisogno di maggior lavoro; una volta completato, possono essere spostate
345 all'interno del kernel nel posto più appropriato. Questo è il modo di tener
346 traccia dei driver che non sono ancora in linea con gli standard di codifica
347 o qualità, ma che le persone potrebbero voler usare ugualmente e tracciarne
350 Greg Kroah-Hartman attualmente gestisce i sorgenti in preparazione. I driver
351 che non sono completamente pronti vengono inviati a lui, e ciascun driver avrà
352 la propria sotto-cartella in drivers/staging/. Assieme ai file sorgenti
353 dei driver, dovrebbe essere presente nella stessa cartella anche un file TODO.
354 Il file TODO elenca il lavoro ancora da fare su questi driver per poter essere
355 accettati nel kernel, e indica anche la lista di persone da inserire in copia
356 conoscenza per ogni modifica fatta. Le regole attuali richiedono che i
357 driver debbano, come minimo, compilare adeguatamente.
359 La *preparazione* può essere una via relativamente facile per inserire nuovi
360 driver all'interno del ramo principale, dove, con un po' di fortuna, saranno
361 notati da altri sviluppatori e migliorati velocemente. Entrare nella fase
362 di preparazione non è però la fine della storia, infatti, il codice che si
363 trova nella cartella staging che non mostra regolari progressi potrebbe
364 essere rimosso. Le distribuzioni, inoltre, tendono a dimostrarsi relativamente
365 riluttanti nell'attivare driver in preparazione. Quindi lo preparazione è,
366 nel migliore dei casi, una tappa sulla strada verso il divenire un driver
373 Come è possibile notare dal testo sopra, il processo di sviluppo del kernel
374 dipende pesantemente dalla capacità di guidare la raccolta di patch in
375 diverse direzioni. L'intera cosa non funzionerebbe se non venisse svolta
376 con l'uso di strumenti appropriati e potenti. Spiegare l'uso di tali
377 strumenti non è lo scopo di questo documento, ma c'è spazio per alcuni
380 In assoluto, nella comunità del kernel, predomina l'uso di git come sistema
381 di gestione dei sorgenti. Git è una delle diverse tipologie di sistemi
382 distribuiti di controllo versione che sono stati sviluppati nella comunità
383 del software libero. Esso è calibrato per lo sviluppo del kernel, e si
384 comporta abbastanza bene quando ha a che fare con repositori grandi e con un
385 vasto numero di patch. Git ha inoltre la reputazione di essere difficile
386 da imparare e utilizzare, benché stia migliorando. Agli sviluppatori
387 del kernel viene richiesta un po' di familiarità con git; anche se non lo
388 utilizzano per il proprio lavoro, hanno bisogno di git per tenersi al passo
389 con il lavoro degli altri sviluppatori (e con il ramo principale).
391 Git è ora compreso in quasi tutte le distribuzioni Linux. Esiste una sito che
396 Qui troverete i riferimenti alla documentazione e alle guide passo-passo.
398 Tra gli sviluppatori Kernel che non usano git, la scelta alternativa più
399 popolare è quasi sicuramente Mercurial:
401 http://www.selenic.com/mercurial/
403 Mercurial condivide diverse caratteristiche con git, ma fornisce
404 un'interfaccia che potrebbe risultare più semplice da utilizzare.
406 L'altro strumento che vale la pena conoscere è Quilt:
408 http://savannah.nongnu.org/projects/quilt/
411 Quilt è un sistema di gestione delle patch, piuttosto che un sistema
412 di gestione dei sorgenti. Non mantiene uno storico degli eventi; ma piuttosto
413 è orientato verso il tracciamento di uno specifico insieme di modifiche
414 rispetto ad un codice in evoluzione. Molti dei più grandi manutentori di
415 sottosistema utilizzano quilt per gestire le patch che dovrebbero essere
416 integrate. Per la gestione di certe tipologie di sorgenti (-mm, per esempio),
417 quilt è il miglior strumento per svolgere il lavoro.
423 Una grossa parte del lavoro di sviluppo del Kernel Linux viene svolto tramite
424 le liste di discussione. È difficile essere un membro della comunità
425 pienamente coinvolto se non si partecipa almeno ad una lista da qualche
426 parte. Ma, le liste di discussione di Linux rappresentano un potenziale
427 problema per gli sviluppatori, che rischiano di venir sepolti da un mare di
428 email, restare incagliati nelle convenzioni in vigore nelle liste Linux,
431 Molte delle liste di discussione del Kernel girano su vger.kernel.org;
432 l'elenco principale lo si trova sul sito:
434 http://vger.kernel.org/vger-lists.html
436 Esistono liste gestite altrove; un certo numero di queste sono in
437 redhat.com/mailman/listinfo.
439 La lista di discussione principale per lo sviluppo del kernel è, ovviamente,
440 linux-kernel. Questa lista è un luogo ostile dove trovarsi; i volumi possono
441 raggiungere i 500 messaggi al giorno, la quantità di "rumore" è elevata,
442 la conversazione può essere strettamente tecnica e i partecipanti non sono
443 sempre preoccupati di mostrare un alto livello di educazione. Ma non esiste
444 altro luogo dove la comunità di sviluppo del kernel si unisce per intero;
445 gli sviluppatori che evitano tale lista si perderanno informazioni importanti.
447 Ci sono alcuni consigli che possono essere utili per sopravvivere a
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.
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.
459 - Non alimentate i troll. Se qualcuno cerca di creare nervosismo, ignoratelo.
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.
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.
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.
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.
480 Infine, la ricerca della corretta lista di discussione è uno degli errori più
481 comuni per gli sviluppatori principianti. Qualcuno che pone una domanda
482 relativa alla rete su linux-kernel riceverà quasi certamente il suggerimento
483 di chiedere sulla lista netdev, che è la lista frequentata dagli sviluppatori
484 di rete. Ci sono poi altre liste per i sottosistemi SCSI, video4linux, IDE,
485 filesystem, etc. Il miglior posto dove cercare una lista di discussione è il
486 file MAINTAINERS che si trova nei sorgenti del kernel.
488 Iniziare con lo sviluppo del Kernel
489 -----------------------------------
491 Sono comuni le domande sul come iniziare con lo sviluppo del kernel - sia da
492 singole persone che da aziende. Altrettanto comuni sono i passi falsi che
493 rendono l'inizio di tale relazione più difficile di quello che dovrebbe essere.
495 Le aziende spesso cercano di assumere sviluppatori noti per creare un gruppo
496 di sviluppo iniziale. Questo, in effetti, può essere una tecnica efficace.
497 Ma risulta anche essere dispendiosa e non va ad accrescere il bacino di
498 sviluppatori kernel con esperienza. È possibile anche "portare a casa"
499 sviluppatori per accelerare lo sviluppo del kernel, dando comunque
500 all'investimento un po' di tempo. Prendersi questo tempo può fornire
501 al datore di lavoro un gruppo di sviluppatori che comprendono sia il kernel
502 che l'azienda stessa, e che possono supportare la formazione di altre persone.
503 Nel medio periodo, questa è spesso uno delle soluzioni più proficue.
505 I singoli sviluppatori sono spesso, comprensibilmente, una perdita come punto
506 di partenza. Iniziare con un grande progetto può rivelarsi intimidatorio;
507 spesso all'inizio si vuole solo verificare il terreno con qualcosa di piccolo.
508 Questa è una delle motivazioni per le quali molti sviluppatori saltano alla
509 creazione di patch che vanno a sistemare errori di battitura o
510 problematiche minori legate allo stile del codice. Sfortunatamente, tali
511 patch creano un certo livello di rumore che distrae l'intera comunità di
512 sviluppo, quindi, sempre di più, esse vengono degradate. I nuovi sviluppatori
513 che desiderano presentarsi alla comunità non riceveranno l'accoglienza
514 che vorrebbero con questi mezzi.
516 Andrew Morton da questo consiglio agli aspiranti sviluppatori kernel
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.
527 (http://lwn.net/Articles/283982/).
529 In assenza di problemi ovvi da risolvere, si consiglia agli sviluppatori
530 di consultare, in generale, la lista di regressioni e di bachi aperti.
531 Non c'è mai carenza di problematiche bisognose di essere sistemate;
532 accollandosi tali questioni gli sviluppatori accumuleranno esperienza con
533 la procedura, ed allo stesso tempo, aumenteranno la loro rispettabilità
534 all'interno della comunità di sviluppo.
projects / linux-2.6-microblaze.git / blob