0001 .. include:: ../disclaimer-ita.rst
0002
0003 :Original: :ref:`Documentation/process/2.Process.rst <development_process>`
0004 :Translator: Alessia Mantegazza <amantegazza@vaga.pv.it>
0005
0006 .. _it_development_process:
0007
0008 Come funziona il processo di sviluppo
0009 =====================================
0010
0011 Lo sviluppo del Kernel agli inizi degli anno '90 era abbastanza libero, con
0012 un numero di utenti e sviluppatori relativamente basso. Con una base
0013 di milioni di utenti e con 2000 sviluppatori coinvolti nel giro di un anno,
0014 il kernel da allora ha messo in atto un certo numero di procedure per rendere
0015 lo sviluppo più agevole. È richiesta una solida conoscenza di come tale
0016 processo si svolge per poter esserne parte attiva.
0017
0018 Il quadro d'insieme
0019 -------------------
0020
0021 Gli sviluppatori kernel utilizzano un calendario di rilascio generico, dove
0022 ogni due o tre mesi viene effettuata un rilascio importante del kernel.
0023 I rilasci più recenti sono stati:
0024
0025 ====== =================
0026 5.0 3 marzo, 2019
0027 5.1 5 maggio, 2019
0028 5.2 7 luglio, 2019
0029 5.3 15 settembre, 2019
0030 5.4 24 novembre, 2019
0031 5.5 6 gennaio, 2020
0032 ====== =================
0033
0034 Ciascun rilascio 5.x è un importante rilascio del kernel con nuove
0035 funzionalità, modifiche interne dell'API, e molto altro. Un tipico
0036 rilascio contiene quasi 13,000 gruppi di modifiche con ulteriori
0037 modifiche a parecchie migliaia di linee di codice. La 5.x. è pertanto la
0038 linea di confine nello sviluppo del kernel Linux; il kernel utilizza un sistema
0039 di sviluppo continuo che integra costantemente nuove importanti modifiche.
0040
0041 Viene seguita una disciplina abbastanza lineare per l'inclusione delle
0042 patch di ogni rilascio. All'inizio di ogni ciclo di sviluppo, la
0043 "finestra di inclusione" viene dichiarata aperta. In quel momento il codice
0044 ritenuto sufficientemente stabile(e che è accettato dalla comunità di sviluppo)
0045 viene incluso nel ramo principale del kernel. La maggior parte delle
0046 patch per un nuovo ciclo di sviluppo (e tutte le più importanti modifiche)
0047 saranno inserite durante questo periodo, ad un ritmo che si attesta sulle
0048 1000 modifiche ("patch" o "gruppo di modifiche") al giorno.
0049
0050 (per inciso, vale la pena notare che i cambiamenti integrati durante la
0051 "finestra di inclusione" non escono dal nulla; questi infatti, sono stati
0052 raccolti e, verificati in anticipo. Il funzionamento di tale procedimento
0053 verrà descritto dettagliatamente più avanti).
0054
0055 La finestra di inclusione resta attiva approssimativamente per due settimane.
0056 Al termine di questo periodo, Linus Torvald dichiarerà che la finestra è
0057 chiusa e rilascerà il primo degli "rc" del kernel.
0058 Per il kernel che è destinato ad essere 5.6, per esempio, il rilascio
0059 che emerge al termine della finestra d'inclusione si chiamerà 5.6-rc1.
0060 Questo rilascio indica che il momento di aggiungere nuovi componenti è
0061 passato, e che è iniziato il periodo di stabilizzazione del prossimo kernel.
0062
0063 Nelle successive sei/dieci settimane, potranno essere sottoposte solo modifiche
0064 che vanno a risolvere delle problematiche. Occasionalmente potrà essere
0065 consentita una modifica più consistente, ma tali occasioni sono rare.
0066 Gli sviluppatori che tenteranno di aggiungere nuovi elementi al di fuori della
0067 finestra di inclusione, tendenzialmente, riceveranno un accoglienza poco
0068 amichevole. Come regola generale: se vi perdete la finestra di inclusione per
0069 un dato componente, la cosa migliore da fare è aspettare il ciclo di sviluppo
0070 successivo (un'eccezione può essere fatta per i driver per hardware non
0071 supportati in precedenza; se toccano codice non facente parte di quello
0072 attuale, che non causino regressioni e che potrebbero essere aggiunti in
0073 sicurezza in un qualsiasi momento)
0074
0075 Mentre le correzioni si aprono la loro strada all'interno del ramo principale,
0076 il ritmo delle modifiche rallenta col tempo. Linus rilascia un nuovo
0077 kernel -rc circa una volta alla settimana; e ne usciranno circa 6 o 9 prima
0078 che il kernel venga considerato sufficientemente stabile e che il rilascio
0079 finale venga fatto. A quel punto tutto il processo ricomincerà.
0080
0081 Esempio: ecco com'è andato il ciclo di sviluppo della versione 5.4
0082 (tutte le date si collocano nel 2018)
0083
0084
0085 ============== =======================================
0086 15 settembre 5.3 rilascio stabile
0087 30 settembre 5.4-rc1, finestra di inclusione chiusa
0088 6 ottobre 5.4-rc2
0089 13 ottobre 5.4-rc3
0090 20 ottobre 5.4-rc4
0091 27 ottobre 5.4-rc5
0092 3 novembre 5.4-rc6
0093 10 novembre 5.4-rc7
0094 17 novembre 5.4-rc8
0095 24 novembre 5.4 rilascio stabile
0096 ============== =======================================
0097
0098 In che modo gli sviluppatori decidono quando chiudere il ciclo di sviluppo e
0099 creare quindi una rilascio stabile? Un metro valido è il numero di regressioni
0100 rilevate nel precedente rilascio. Nessun baco è il benvenuto, ma quelli che
0101 procurano problemi su sistemi che hanno funzionato in passato sono considerati
0102 particolarmente seri. Per questa ragione, le modifiche che portano ad una
0103 regressione sono viste sfavorevolmente e verranno quasi sicuramente annullate
0104 durante il periodo di stabilizzazione.
0105
0106 L'obiettivo degli sviluppatori è quello di aggiustare tutte le regressioni
0107 conosciute prima che avvenga il rilascio stabile. Nel mondo reale, questo
0108 tipo di perfezione difficilmente viene raggiunta; esistono troppe variabili
0109 in un progetto di questa portata. Arriva un punto dove ritardare il rilascio
0110 finale peggiora la situazione; la quantità di modifiche in attesa della
0111 prossima finestra di inclusione crescerà enormemente, creando ancor più
0112 regressioni al giro successivo. Quindi molti kernel 5.x escono con una
0113 manciata di regressioni delle quali, si spera, nessuna è grave.
0114
0115 Una volta che un rilascio stabile è fatto, il suo costante mantenimento è
0116 affidato al "squadra stabilità", attualmente composta da Greg Kroah-Hartman.
0117 Questa squadra rilascia occasionalmente degli aggiornamenti relativi al
0118 rilascio stabile usando la numerazione 5.x.y. Per essere presa in
0119 considerazione per un rilascio d'aggiornamento, una modifica deve:
0120 (1) correggere un baco importante (2) essere già inserita nel ramo principale
0121 per il prossimo sviluppo del kernel. Solitamente, passato il loro rilascio
0122 iniziale, i kernel ricevono aggiornamenti per più di un ciclo di sviluppo.
0123 Quindi, per esempio, la storia del kernel 5.2 appare così (anno 2019):
0124
0125 ============== ===============================
0126 7 luglio 5.2 rilascio stabile
0127 14 luglio 5.2.1
0128 21 luglio 5.2.2
0129 26 luglio 5.2.3
0130 28 luglio 5.2.4
0131 31 luglio 5.2.5
0132 ... ...
0133 11 ottobre 5.2.21
0134 ============== ===============================
0135
0136 La 5.2.21 fu l'aggiornamento finale per la versione 5.2.
0137
0138 Alcuni kernel sono destinati ad essere kernel a "lungo termine"; questi
0139 riceveranno assistenza per un lungo periodo di tempo. Al momento in cui
0140 scriviamo, i manutentori dei kernel stabili a lungo termine sono:
0141
0142 ====== ================================ ==========================================
0143 3.16 Ben Hutchings (kernel stabile molto più a lungo termine)
0144 4.4 Greg Kroah-Hartman e Sasha Levin (kernel stabile molto più a lungo termine)
0145 4.9 Greg Kroah-Hartman e Sasha Levin
0146 4.14 Greg Kroah-Hartman e Sasha Levin
0147 4.19 Greg Kroah-Hartman e Sasha Levin
0148 5.4i Greg Kroah-Hartman e Sasha Levin
0149 ====== ================================ ==========================================
0150
0151
0152 Questa selezione di kernel di lungo periodo sono puramente dovuti ai loro
0153 manutentori, alla loro necessità e al tempo per tenere aggiornate proprio
0154 quelle versioni. Non ci sono altri kernel a lungo termine in programma per
0155 alcun rilascio in arrivo.
0156
0157 Il ciclo di vita di una patch
0158 -----------------------------
0159
0160 Le patch non passano direttamente dalla tastiera dello sviluppatori
0161 al ramo principale del kernel. Esiste, invece, una procedura disegnata
0162 per assicurare che ogni patch sia di buona qualità e desiderata nel
0163 ramo principale. Questo processo avviene velocemente per le correzioni
0164 meno importanti, o, nel caso di patch ampie e controverse, va avanti per anni.
0165 Per uno sviluppatore la maggior frustrazione viene dalla mancanza di
0166 comprensione di questo processo o dai tentativi di aggirarlo.
0167
0168 Nella speranza di ridurre questa frustrazione, questo documento spiegherà
0169 come una patch viene inserita nel kernel. Ciò che segue è un'introduzione
0170 che descrive il processo ideale. Approfondimenti verranno invece trattati
0171 più avanti.
0172
0173 Una patch attraversa, generalmente, le seguenti fasi:
0174
0175 - Progetto. In questa fase sono stabilite quelli che sono i requisiti
0176 della modifica - e come verranno soddisfatti. Il lavoro di progettazione
0177 viene spesso svolto senza coinvolgere la comunità, ma è meglio renderlo
0178 il più aperto possibile; questo può far risparmiare molto tempo evitando
0179 eventuali riprogettazioni successive.
0180
0181 - Prima revisione. Le patch vengono pubblicate sulle liste di discussione
0182 interessate, e gli sviluppatori in quella lista risponderanno coi loro
0183 commenti. Se si svolge correttamente, questo procedimento potrebbe far
0184 emergere problemi rilevanti in una patch.
0185
0186 - Revisione più ampia. Quando la patch è quasi pronta per essere inserita
0187 nel ramo principale, un manutentore importante del sottosistema dovrebbe
0188 accettarla - anche se, questa accettazione non è una garanzia che la
0189 patch arriverà nel ramo principale. La patch sarà visibile nei sorgenti
0190 del sottosistema in questione e nei sorgenti -next (descritti sotto).
0191 Quando il processo va a buon fine, questo passo porta ad una revisione
0192 più estesa della patch e alla scoperta di problemi d'integrazione
0193 con il lavoro altrui.
0194
0195 - Per favore, tenete da conto che la maggior parte dei manutentori ha
0196 anche un lavoro quotidiano, quindi integrare le vostre patch potrebbe
0197 non essere la loro priorità più alta. Se una vostra patch riceve
0198 dei suggerimenti su dei cambiamenti necessari, dovreste applicare
0199 quei cambiamenti o giustificare perché non sono necessari. Se la vostra
0200 patch non riceve alcuna critica ma non è stata integrata dal
0201 manutentore del driver o sottosistema, allora dovreste continuare con
0202 i necessari aggiornamenti per mantenere la patch aggiornata al kernel
0203 più recente cosicché questa possa integrarsi senza problemi; continuate
0204 ad inviare gli aggiornamenti per essere revisionati e integrati.
0205
0206 - Inclusione nel ramo principale. Eventualmente, una buona patch verrà
0207 inserita all'interno nel repositorio principale, gestito da
0208 Linus Torvalds. In questa fase potrebbero emergere nuovi problemi e/o
0209 commenti; è importante che lo sviluppatore sia collaborativo e che sistemi
0210 ogni questione che possa emergere.
0211
0212 - Rilascio stabile. Ora, il numero di utilizzatori che sono potenzialmente
0213 toccati dalla patch è aumentato, quindi, ancora una volta, potrebbero
0214 emergere nuovi problemi.
0215
0216 - Manutenzione di lungo periodo. Nonostante sia possibile che uno sviluppatore
0217 si dimentichi del codice dopo la sua integrazione, questo comportamento
0218 lascia una brutta impressione nella comunità di sviluppo. Integrare il
0219 codice elimina alcuni degli oneri facenti parte della manutenzione, in
0220 particolare, sistemerà le problematiche causate dalle modifiche all'API.
0221 Ma lo sviluppatore originario dovrebbe continuare ad assumersi la
0222 responsabilità per il codice se quest'ultimo continua ad essere utile
0223 nel lungo periodo.
0224
0225 Uno dei più grandi errori fatti dagli sviluppatori kernel (o dai loro datori
0226 di lavoro) è quello di cercare di ridurre tutta la procedura ad una singola
0227 "integrazione nel remo principale". Questo approccio inevitabilmente conduce
0228 a una condizione di frustrazione per tutti coloro che sono coinvolti.
0229
0230 Come le modifiche finiscono nel Kernel
0231 --------------------------------------
0232
0233 Esiste una sola persona che può inserire le patch nel repositorio principale
0234 del kernel: Linus Torvalds. Ma, per esempio, di tutte le 9500 patch
0235 che entrarono nella versione 2.6.38 del kernel, solo 112 (circa
0236 l'1,3%) furono scelte direttamente da Linus in persona. Il progetto
0237 del kernel è cresciuto fino a raggiungere una dimensione tale per cui
0238 un singolo sviluppatore non può controllare e selezionare
0239 indipendentemente ogni modifica senza essere supportato. La via
0240 scelta dagli sviluppatori per indirizzare tale crescita è stata quella
0241 di utilizzare un sistema di "sottotenenti" basato sulla fiducia.
0242
0243 Il codice base del kernel è spezzato in una serie si sottosistemi: rete,
0244 supporto per specifiche architetture, gestione della memoria, video e
0245 strumenti, etc. Molti sottosistemi hanno un manutentore designato: ovvero uno
0246 sviluppatore che ha piena responsabilità di tutto il codice presente in quel
0247 sottosistema. Tali manutentori di sottosistema sono i guardiani
0248 (in un certo senso) della parte di kernel che gestiscono; sono coloro che
0249 (solitamente) accetteranno una patch per l'inclusione nel ramo principale
0250 del kernel.
0251
0252 I manutentori di sottosistema gestiscono ciascuno la propria parte dei sorgenti
0253 del kernel, utilizzando abitualmente (ma certamente non sempre) git.
0254 Strumenti come git (e affini come quilt o mercurial) permettono ai manutentori
0255 di stilare una lista delle patch, includendo informazioni sull'autore ed
0256 altri metadati. In ogni momento, il manutentore può individuare quale patch
0257 nel sua repositorio non si trova nel ramo principale.
0258
0259 Quando la "finestra di integrazione" si apre, i manutentori di alto livello
0260 chiederanno a Linus di "prendere" dai loro repositori le modifiche che hanno
0261 selezionato per l'inclusione. Se Linus acconsente, il flusso di patch si
0262 convoglierà nel repositorio di quest ultimo, divenendo così parte del ramo
0263 principale del kernel. La quantità d'attenzione che Linus presta alle
0264 singole patch ricevute durante l'operazione di integrazione varia.
0265 È chiaro che, qualche volta, guardi più attentamente. Ma, come regola
0266 generale, Linus confida nel fatto che i manutentori di sottosistema non
0267 selezionino pessime patch.
0268
0269 I manutentori di sottosistemi, a turno, possono "prendere" patch
0270 provenienti da altri manutentori. Per esempio, i sorgenti per la rete rete
0271 sono costruiti da modifiche che si sono accumulate inizialmente nei sorgenti
0272 dedicati ai driver per dispositivi di rete, rete senza fili, ecc. Tale
0273 catena di repositori può essere più o meno lunga, benché raramente ecceda
0274 i due o tre collegamenti. Questo processo è conosciuto come
0275 "la catena della fiducia", perché ogni manutentore all'interno della
0276 catena si fida di coloro che gestiscono i livelli più bassi.
0277
0278 Chiaramente, in un sistema come questo, l'inserimento delle patch all'interno
0279 del kernel si basa sul trovare il manutentore giusto. Di norma, inviare
0280 patch direttamente a Linus non è la via giusta.
0281
0282
0283 Sorgenti -next
0284 --------------
0285
0286 La catena di sottosistemi guida il flusso di patch all'interno del kernel,
0287 ma solleva anche un interessante quesito: se qualcuno volesse vedere tutte le
0288 patch pronte per la prossima finestra di integrazione?
0289 Gli sviluppatori si interesseranno alle patch in sospeso per verificare
0290 che non ci siano altri conflitti di cui preoccuparsi; una modifica che, per
0291 esempio, cambia il prototipo di una funzione fondamentale del kernel andrà in
0292 conflitto con qualsiasi altra modifica che utilizzi la vecchia versione di
0293 quella funzione. Revisori e tester vogliono invece avere accesso alle
0294 modifiche nella loro totalità prima che approdino nel ramo principale del
0295 kernel. Uno potrebbe prendere le patch provenienti da tutti i sottosistemi
0296 d'interesse, ma questo sarebbe un lavoro enorme e fallace.
0297
0298 La risposta ci viene sotto forma di sorgenti -next, dove i sottosistemi sono
0299 raccolti per essere testati e controllati. Il più vecchio di questi sorgenti,
0300 gestito da Andrew Morton, è chiamato "-mm" (memory management, che è l'inizio
0301 di tutto). L'-mm integra patch proveniente da una lunga lista di sottosistemi;
0302 e ha, inoltre, alcune patch destinate al supporto del debugging.
0303
0304 Oltre a questo, -mm contiene una raccolta significativa di patch che sono
0305 state selezionate da Andrew direttamente. Queste patch potrebbero essere
0306 state inviate in una lista di discussione, o possono essere applicate ad una
0307 parte del kernel per la quale non esiste un sottosistema dedicato.
0308 Di conseguenza, -mm opera come una specie di sottosistema "ultima spiaggia";
0309 se per una patch non esiste una via chiara per entrare nel ramo principale,
0310 allora è probabile che finirà in -mm. Le patch passate per -mm
0311 eventualmente finiranno nel sottosistema più appropriato o saranno inviate
0312 direttamente a Linus. In un tipico ciclo di sviluppo, circa il 5-10% delle
0313 patch andrà nel ramo principale attraverso -mm.
0314
0315 La patch -mm correnti sono disponibili nella cartella "mmotm" (-mm of
0316 the moment) all'indirizzo:
0317
0318 http://www.ozlabs.org/~akpm/mmotm/
0319
0320 È molto probabile che l'uso dei sorgenti MMOTM diventi un'esperienza
0321 frustrante; ci sono buone probabilità che non compili nemmeno.
0322
0323 I sorgenti principali per il prossimo ciclo d'integrazione delle patch
0324 è linux-next, gestito da Stephen Rothwell. I sorgenti linux-next sono, per
0325 definizione, un'istantanea di come dovrà apparire il ramo principale dopo che
0326 la prossima finestra di inclusione si chiuderà. I linux-next sono annunciati
0327 sulla lista di discussione linux-kernel e linux-next nel momento in cui
0328 vengono assemblati; e possono essere scaricate da:
0329
0330 http://www.kernel.org/pub/linux/kernel/next/
0331
0332 Linux-next è divenuto parte integrante del processo di sviluppo del kernel;
0333 tutte le patch incorporate durante una finestra di integrazione dovrebbero
0334 aver trovato la propria strada in linux-next, a volte anche prima dell'apertura
0335 della finestra di integrazione.
0336
0337
0338 Sorgenti in preparazione
0339 ------------------------
0340
0341 Nei sorgenti del kernel esiste la cartella drivers/staging/, dove risiedono
0342 molte sotto-cartelle per i driver o i filesystem che stanno per essere aggiunti
0343 al kernel. Questi restano nella cartella drivers/staging fintanto che avranno
0344 bisogno di maggior lavoro; una volta completato, possono essere spostate
0345 all'interno del kernel nel posto più appropriato. Questo è il modo di tener
0346 traccia dei driver che non sono ancora in linea con gli standard di codifica
0347 o qualità, ma che le persone potrebbero voler usare ugualmente e tracciarne
0348 lo sviluppo.
0349
0350 Greg Kroah-Hartman attualmente gestisce i sorgenti in preparazione. I driver
0351 che non sono completamente pronti vengono inviati a lui, e ciascun driver avrà
0352 la propria sotto-cartella in drivers/staging/. Assieme ai file sorgenti
0353 dei driver, dovrebbe essere presente nella stessa cartella anche un file TODO.
0354 Il file TODO elenca il lavoro ancora da fare su questi driver per poter essere
0355 accettati nel kernel, e indica anche la lista di persone da inserire in copia
0356 conoscenza per ogni modifica fatta. Le regole attuali richiedono che i
0357 driver debbano, come minimo, compilare adeguatamente.
0358
0359 La *preparazione* può essere una via relativamente facile per inserire nuovi
0360 driver all'interno del ramo principale, dove, con un po' di fortuna, saranno
0361 notati da altri sviluppatori e migliorati velocemente. Entrare nella fase
0362 di preparazione non è però la fine della storia, infatti, il codice che si
0363 trova nella cartella staging che non mostra regolari progressi potrebbe
0364 essere rimosso. Le distribuzioni, inoltre, tendono a dimostrarsi relativamente
0365 riluttanti nell'attivare driver in preparazione. Quindi lo preparazione è,
0366 nel migliore dei casi, una tappa sulla strada verso il divenire un driver
0367 del ramo principale.
0368
0369
0370 Strumenti
0371 ---------
0372
0373 Come è possibile notare dal testo sopra, il processo di sviluppo del kernel
0374 dipende pesantemente dalla capacità di guidare la raccolta di patch in
0375 diverse direzioni. L'intera cosa non funzionerebbe se non venisse svolta
0376 con l'uso di strumenti appropriati e potenti. Spiegare l'uso di tali
0377 strumenti non è lo scopo di questo documento, ma c'è spazio per alcuni
0378 consigli.
0379
0380 In assoluto, nella comunità del kernel, predomina l'uso di git come sistema
0381 di gestione dei sorgenti. Git è una delle diverse tipologie di sistemi
0382 distribuiti di controllo versione che sono stati sviluppati nella comunità
0383 del software libero. Esso è calibrato per lo sviluppo del kernel, e si
0384 comporta abbastanza bene quando ha a che fare con repositori grandi e con un
0385 vasto numero di patch. Git ha inoltre la reputazione di essere difficile
0386 da imparare e utilizzare, benché stia migliorando. Agli sviluppatori
0387 del kernel viene richiesta un po' di familiarità con git; anche se non lo
0388 utilizzano per il proprio lavoro, hanno bisogno di git per tenersi al passo
0389 con il lavoro degli altri sviluppatori (e con il ramo principale).
0390
0391 Git è ora compreso in quasi tutte le distribuzioni Linux. Esiste una sito che
0392 potete consultare:
0393
0394 http://git-scm.com/
0395
0396 Qui troverete i riferimenti alla documentazione e alle guide passo-passo.
0397
0398 Tra gli sviluppatori Kernel che non usano git, la scelta alternativa più
0399 popolare è quasi sicuramente Mercurial:
0400
0401 http://www.selenic.com/mercurial/
0402
0403 Mercurial condivide diverse caratteristiche con git, ma fornisce
0404 un'interfaccia che potrebbe risultare più semplice da utilizzare.
0405
0406 L'altro strumento che vale la pena conoscere è Quilt:
0407
0408 http://savannah.nongnu.org/projects/quilt/
0409
0410
0411 Quilt è un sistema di gestione delle patch, piuttosto che un sistema
0412 di gestione dei sorgenti. Non mantiene uno storico degli eventi; ma piuttosto
0413 è orientato verso il tracciamento di uno specifico insieme di modifiche
0414 rispetto ad un codice in evoluzione. Molti dei più grandi manutentori di
0415 sottosistema utilizzano quilt per gestire le patch che dovrebbero essere
0416 integrate. Per la gestione di certe tipologie di sorgenti (-mm, per esempio),
0417 quilt è il miglior strumento per svolgere il lavoro.
0418
0419
0420 Liste di discussione
0421 --------------------
0422
0423 Una grossa parte del lavoro di sviluppo del Kernel Linux viene svolto tramite
0424 le liste di discussione. È difficile essere un membro della comunità
0425 pienamente coinvolto se non si partecipa almeno ad una lista da qualche
0426 parte. Ma, le liste di discussione di Linux rappresentano un potenziale
0427 problema per gli sviluppatori, che rischiano di venir sepolti da un mare di
0428 email, restare incagliati nelle convenzioni in vigore nelle liste Linux,
0429 o entrambi.
0430
0431 Molte delle liste di discussione del Kernel girano su vger.kernel.org;
0432 l'elenco principale lo si trova sul sito:
0433
0434 http://vger.kernel.org/vger-lists.html
0435
0436 Esistono liste gestite altrove; un certo numero di queste sono in
0437 redhat.com/mailman/listinfo.
0438
0439 La lista di discussione principale per lo sviluppo del kernel è, ovviamente,
0440 linux-kernel. Questa lista è un luogo ostile dove trovarsi; i volumi possono
0441 raggiungere i 500 messaggi al giorno, la quantità di "rumore" è elevata,
0442 la conversazione può essere strettamente tecnica e i partecipanti non sono
0443 sempre preoccupati di mostrare un alto livello di educazione. Ma non esiste
0444 altro luogo dove la comunità di sviluppo del kernel si unisce per intero;
0445 gli sviluppatori che evitano tale lista si perderanno informazioni importanti.
0446
0447 Ci sono alcuni consigli che possono essere utili per sopravvivere a
0448 linux-kernel:
0449
0450 - Tenete la lista in una cartella separata, piuttosto che inserirla nella
0451 casella di posta principale. Così da essere in grado di ignorare il flusso
0452 di mail per un certo periodo di tempo.
0453
0454 - Non cercate di seguire ogni conversazione - nessuno lo fa. È importante
0455 filtrare solo gli argomenti d'interesse (sebbene va notato che le
0456 conversazioni di lungo periodo possono deviare dall'argomento originario
0457 senza cambiare il titolo della mail) e le persone che stanno partecipando.
0458
0459 - Non alimentate i troll. Se qualcuno cerca di creare nervosismo, ignoratelo.
0460
0461 - Quando rispondete ad una mail linux-kernel (o ad altre liste) mantenete
0462 tutti i Cc:. In assenza di importanti motivazioni (come una richiesta
0463 esplicita), non dovreste mai togliere destinatari. Assicuratevi sempre che
0464 la persona alla quale state rispondendo sia presente nella lista Cc. Questa
0465 usanza fa si che divenga inutile chiedere esplicitamente di essere inseriti
0466 in copia nel rispondere al vostro messaggio.
0467
0468 - Cercate nell'archivio della lista (e nella rete nella sua totalità) prima
0469 di far domande. Molti sviluppatori possono divenire impazienti con le
0470 persone che chiaramente non hanno svolto i propri compiti a casa.
0471
0472 - Evitate il *top-posting* (cioè la pratica di mettere la vostra risposta sopra
0473 alla frase alla quale state rispondendo). Ciò renderebbe la vostra risposta
0474 difficile da leggere e genera scarsa impressione.
0475
0476 - Chiedete nella lista di discussione corretta. Linux-kernel può essere un
0477 punto di incontro generale, ma non è il miglior posto dove trovare
0478 sviluppatori da tutti i sottosistemi.
0479
0480 Infine, la ricerca della corretta lista di discussione è uno degli errori più
0481 comuni per gli sviluppatori principianti. Qualcuno che pone una domanda
0482 relativa alla rete su linux-kernel riceverà quasi certamente il suggerimento
0483 di chiedere sulla lista netdev, che è la lista frequentata dagli sviluppatori
0484 di rete. Ci sono poi altre liste per i sottosistemi SCSI, video4linux, IDE,
0485 filesystem, etc. Il miglior posto dove cercare una lista di discussione è il
0486 file MAINTAINERS che si trova nei sorgenti del kernel.
0487
0488 Iniziare con lo sviluppo del Kernel
0489 -----------------------------------
0490
0491 Sono comuni le domande sul come iniziare con lo sviluppo del kernel - sia da
0492 singole persone che da aziende. Altrettanto comuni sono i passi falsi che
0493 rendono l'inizio di tale relazione più difficile di quello che dovrebbe essere.
0494
0495 Le aziende spesso cercano di assumere sviluppatori noti per creare un gruppo
0496 di sviluppo iniziale. Questo, in effetti, può essere una tecnica efficace.
0497 Ma risulta anche essere dispendiosa e non va ad accrescere il bacino di
0498 sviluppatori kernel con esperienza. È possibile anche "portare a casa"
0499 sviluppatori per accelerare lo sviluppo del kernel, dando comunque
0500 all'investimento un po' di tempo. Prendersi questo tempo può fornire
0501 al datore di lavoro un gruppo di sviluppatori che comprendono sia il kernel
0502 che l'azienda stessa, e che possono supportare la formazione di altre persone.
0503 Nel medio periodo, questa è spesso uno delle soluzioni più proficue.
0504
0505 I singoli sviluppatori sono spesso, comprensibilmente, una perdita come punto
0506 di partenza. Iniziare con un grande progetto può rivelarsi intimidatorio;
0507 spesso all'inizio si vuole solo verificare il terreno con qualcosa di piccolo.
0508 Questa è una delle motivazioni per le quali molti sviluppatori saltano alla
0509 creazione di patch che vanno a sistemare errori di battitura o
0510 problematiche minori legate allo stile del codice. Sfortunatamente, tali
0511 patch creano un certo livello di rumore che distrae l'intera comunità di
0512 sviluppo, quindi, sempre di più, esse vengono degradate. I nuovi sviluppatori
0513 che desiderano presentarsi alla comunità non riceveranno l'accoglienza
0514 che vorrebbero con questi mezzi.
0515
0516 Andrew Morton da questo consiglio agli aspiranti sviluppatori kernel
0517
0518 ::
0519
0520 Il primo progetto per un neofita del kernel dovrebbe essere
0521 sicuramente quello di "assicurarsi che il kernel funzioni alla
0522 perfezione sempre e su tutte le macchine sulle quali potete stendere
0523 la vostra mano". Solitamente il modo per fare ciò è quello di
0524 collaborare con gli altri nel sistemare le cose (questo richiede
0525 persistenza!) ma va bene - è parte dello sviluppo kernel.
0526
0527 (http://lwn.net/Articles/283982/).
0528
0529 In assenza di problemi ovvi da risolvere, si consiglia agli sviluppatori
0530 di consultare, in generale, la lista di regressioni e di bachi aperti.
0531 Non c'è mai carenza di problematiche bisognose di essere sistemate;
0532 accollandosi tali questioni gli sviluppatori accumuleranno esperienza con
0533 la procedura, ed allo stesso tempo, aumenteranno la loro rispettabilità
0534 all'interno della comunità di sviluppo.
