1.Intro.rst (16983B)
1.. include:: ../disclaimer-ita.rst 2 3:Original: :ref:`Documentation/process/1.Intro.rst <development_process_intro>` 4:Translator: Alessia Mantegazza <amantegazza@vaga.pv.it> 5 6.. _it_development_intro: 7 8Introduzione 9============ 10 11Riepilogo generale 12------------------ 13 14Il resto di questa sezione riguarda il processo di sviluppo del kernel e 15quella sorta di frustrazione che gli sviluppatori e i loro datori di lavoro 16potrebbero dover affrontare. Ci sono molte ragioni per le quali del codice 17per il kernel debba essere incorporato nel kernel ufficiale, fra le quali: 18disponibilità immediata agli utilizzatori, supporto della comunità in 19differenti modalità, e la capacità di influenzare la direzione dello sviluppo 20del kernel. 21Il codice che contribuisce al kernel Linux deve essere reso disponibile sotto 22una licenza GPL-compatibile. 23 24La sezione :ref:`it_development_process` introduce il processo di sviluppo, 25il ciclo di rilascio del kernel, ed i meccanismi della finestra 26d'incorporazione. Il capitolo copre le varie fasi di una modifica: sviluppo, 27revisione e ciclo d'incorporazione. Ci sono alcuni dibattiti su strumenti e 28liste di discussione. Gli sviluppatori che sono in attesa di poter sviluppare 29qualcosa per il kernel sono invitati ad individuare e sistemare bachi come 30esercizio iniziale. 31 32La sezione :ref:`it_development_early_stage` copre i primi stadi della 33pianificazione di un progetto di sviluppo, con particolare enfasi sul 34coinvolgimento della comunità, il prima possibile. 35 36La sezione :ref:`it_development_coding` riguarda il processo di scrittura 37del codice. Qui, sono esposte le diverse insidie che sono state già affrontate 38da altri sviluppatori. Il capitolo copre anche alcuni dei requisiti per le 39modifiche, ed esiste un'introduzione ad alcuni strumenti che possono aiutarvi 40nell'assicurarvi che le modifiche per il kernel siano corrette. 41 42La sezione :ref:`it_development_posting` parla del processo di pubblicazione 43delle modifiche per la revisione. Per essere prese in considerazione dalla 44comunità di sviluppo, le modifiche devono essere propriamente formattate ed 45esposte, e devono essere inviate nel posto giusto. Seguire i consigli presenti 46in questa sezione dovrebbe essere d'aiuto nell'assicurare la migliore 47accoglienza possibile del vostro lavoro. 48 49La sezione :ref:`it_development_followthrough` copre ciò che accade dopo 50la pubblicazione delle modifiche; a questo punto il lavoro è lontano 51dall'essere concluso. Lavorare con i revisori è una parte cruciale del 52processo di sviluppo; questa sezione offre una serie di consigli su come 53evitare problemi in questa importante fase. Gli sviluppatori sono diffidenti 54nell'affermare che il lavoro è concluso quando una modifica è incorporata nei 55sorgenti principali. 56 57La sezione :ref:`it_development_advancedtopics` introduce un paio di argomenti 58"avanzati": gestire le modifiche con git e controllare le modifiche pubblicate 59da altri. 60 61La sezione :ref:`it_development_conclusion` chiude il documento con dei 62riferimenti ad altre fonti che forniscono ulteriori informazioni sullo sviluppo 63del kernel. 64 65Di cosa parla questo documento 66------------------------------ 67 68Il kernel Linux, ha oltre 8 milioni di linee di codice e ben oltre 1000 69contributori ad ogni rilascio; è uno dei più vasti e più attivi software 70liberi progettati mai esistiti. Sin dal sul modesto inizio nel 1991, 71questo kernel si è evoluto nel miglior componente per sistemi operativi 72che fanno funzionare piccoli riproduttori musicali, PC, grandi super computer 73e tutte le altre tipologie di sistemi fra questi estremi. È una soluzione 74robusta, efficiente ed adattabile a praticamente qualsiasi situazione. 75 76Con la crescita di Linux è arrivato anche un aumento di sviluppatori 77(ed aziende) desiderosi di partecipare a questo sviluppo. I produttori di 78hardware vogliono assicurarsi che il loro prodotti siano supportati da Linux, 79rendendo questi prodotti attrattivi agli utenti Linux. I produttori di 80sistemi integrati, che usano Linux come componente di un prodotto integrato, 81vogliono che Linux sia capace ed adeguato agli obiettivi ed il più possibile 82alla mano. Fornitori ed altri produttori di software che basano i propri 83prodotti su Linux hanno un chiaro interesse verso capacità, prestazioni ed 84affidabilità del kernel Linux. E gli utenti finali, anche, spesso vorrebbero 85cambiare Linux per renderlo più aderente alle proprie necessità. 86 87Una delle caratteristiche più coinvolgenti di Linux è quella dell'accessibilità 88per gli sviluppatori; chiunque con le capacità richieste può migliorare 89Linux ed influenzarne la direzione di sviluppo. Prodotti non open-source non 90possono offrire questo tipo di apertura, che è una caratteristica del software 91libero. Ma, anzi, il kernel è persino più aperto rispetto a molti altri 92progetti di software libero. Un classico ciclo di sviluppo trimestrale può 93coinvolgere 1000 sviluppatori che lavorano per più di 100 differenti aziende 94(o per nessuna azienda). 95 96Lavorare con la comunità di sviluppo del kernel non è particolarmente 97difficile. Ma, ciononostante, diversi potenziali contributori hanno trovato 98delle difficoltà quando hanno cercato di lavorare sul kernel. La comunità del 99kernel utilizza un proprio modo di operare che gli permette di funzionare 100agevolmente (e genera un prodotto di alta qualità) in un ambiente dove migliaia 101di stringhe di codice sono modificate ogni giorni. Quindi non deve sorprendere 102che il processo di sviluppo del kernel differisca notevolmente dai metodi di 103sviluppo privati. 104 105Il processo di sviluppo del Kernel può, dall'altro lato, risultare 106intimidatorio e strano ai nuovi sviluppatori, ma ha dietro di se buone ragioni 107e solide esperienze. Uno sviluppatore che non comprende i modi della comunità 108del kernel (o, peggio, che cerchi di aggirarli o violarli) avrà un'esperienza 109deludente nel proprio bagaglio. La comunità di sviluppo, sebbene sia utile 110a coloro che cercano di imparare, ha poco tempo da dedicare a coloro che non 111ascoltano o coloro che non sono interessati al processo di sviluppo. 112 113Si spera che coloro che leggono questo documento saranno in grado di evitare 114queste esperienze spiacevoli. C'è molto materiale qui, ma lo sforzo della 115lettura sarà ripagato in breve tempo. La comunità di sviluppo ha sempre 116bisogno di sviluppatori che vogliano aiutare a rendere il kernel migliore; 117il testo seguente potrebbe esservi d'aiuto - o essere d'aiuto ai vostri 118collaboratori- per entrare a far parte della nostra comunità. 119 120Crediti 121------- 122 123Questo documento è stato scritto da Jonathan Corbet, corbet@lwn.net. 124È stato migliorato da Johannes Berg, James Berry, Alex Chiang, Roland 125Dreier, Randy Dunlap, Jake Edge, Jiri Kosina, Matt Mackall, Arthur Marsh, 126Amanda McPherson, Andrew Morton, Andrew Price, Tsugikazu Shibata e Jochen Voß. 127 128Questo lavoro è stato supportato dalla Linux Foundation; un ringraziamento 129speciale ad Amanda McPherson, che ha visto il valore di questo lavoro e lo ha 130reso possibile. 131 132L'importanza d'avere il codice nei sorgenti principali 133------------------------------------------------------ 134 135Alcune aziende e sviluppatori ogni tanto si domandano perché dovrebbero 136preoccuparsi di apprendere come lavorare con la comunità del kernel e di 137inserire il loro codice nel ramo di sviluppo principale (per ramo principale 138s'intende quello mantenuto da Linus Torvalds e usato come base dai 139distributori Linux). Nel breve termine, contribuire al codice può sembrare 140un costo inutile; può sembra più facile tenere separato il proprio codice e 141supportare direttamente i suoi utilizzatori. La verità è che il tenere il 142codice separato ("fuori dai sorgenti", *"out-of-tree"*) è un falso risparmio. 143 144Per dimostrare i costi di un codice "fuori dai sorgenti", eccovi 145alcuni aspetti rilevanti del processo di sviluppo kernel; la maggior parte 146di essi saranno approfonditi dettagliatamente più avanti in questo documento. 147Considerate: 148 149- Il codice che è stato inserito nel ramo principale del kernel è disponibile 150 a tutti gli utilizzatori Linux. Sarà automaticamente presente in tutte le 151 distribuzioni che lo consentono. Non c'è bisogno di: driver per dischi, 152 scaricare file, o della scocciatura del dover supportare diverse versioni di 153 diverse distribuzioni; funziona già tutto, per gli sviluppatori e per gli 154 utilizzatori. L'inserimento nel ramo principale risolve un gran numero di 155 problemi di distribuzione e di supporto. 156 157- Nonostante gli sviluppatori kernel si sforzino di tenere stabile 158 l'interfaccia dello spazio utente, quella interna al kernel è in continuo 159 cambiamento. La mancanza di un'interfaccia interna è deliberatamente una 160 decisione di progettazione; ciò permette che i miglioramenti fondamentali 161 vengano fatti in un qualsiasi momento e che risultino fatti con un codice di 162 alta qualità. Ma una delle conseguenze di questa politica è che qualsiasi 163 codice "fuori dai sorgenti" richiede costante manutenzione per renderlo 164 funzionante coi kernel più recenti. Tenere un codice "fuori dai sorgenti" 165 richiede una mole di lavoro significativa solo per farlo funzionare. 166 167 Invece, il codice che si trova nel ramo principale non necessita di questo 168 tipo di lavoro poiché ad ogni sviluppatore che faccia una modifica alle 169 interfacce viene richiesto di sistemare anche il codice che utilizza 170 quell'interfaccia. Quindi, il codice che è stato inserito nel ramo principale 171 ha dei costi di mantenimento significativamente più bassi. 172 173- Oltre a ciò, spesso il codice che è all'interno del kernel sarà migliorato da 174 altri sviluppatori. Dare pieni poteri alla vostra comunità di utenti e ai 175 clienti può portare a sorprendenti risultati che migliorano i vostri 176 prodotti. 177 178- Il codice kernel è soggetto a revisioni, sia prima che dopo l'inserimento 179 nel ramo principale. Non importa quanto forti fossero le abilità dello 180 sviluppatore originale, il processo di revisione troverà il modo di migliore 181 il codice. Spesso la revisione trova bachi importanti e problemi di 182 sicurezza. Questo è particolarmente vero per il codice che è stato 183 sviluppato in un ambiente chiuso; tale codice ottiene un forte beneficio 184 dalle revisioni provenienti da sviluppatori esteri. Il codice 185 "fuori dai sorgenti", invece, è un codice di bassa qualità. 186 187- La partecipazione al processo di sviluppo costituisce la vostra via per 188 influenzare la direzione di sviluppo del kernel. Gli utilizzatori che 189 "reclamano da bordo campo" sono ascoltati, ma gli sviluppatori attivi 190 hanno una voce più forte - e la capacità di implementare modifiche che 191 renderanno il kernel più funzionale alle loro necessità. 192 193- Quando il codice è gestito separatamente, esiste sempre la possibilità che 194 terze parti contribuiscano con una differente implementazione che fornisce 195 le stesse funzionalità. Se dovesse accadere, l'inserimento del codice 196 diventerà molto più difficile - fino all'impossibilità. Poi, dovrete far 197 fronte a delle alternative poco piacevoli, come: (1) mantenere un elemento 198 non standard "fuori dai sorgenti" per un tempo indefinito, o (2) abbandonare 199 il codice e far migrare i vostri utenti alla versione "nei sorgenti". 200 201- Contribuire al codice è l'azione fondamentale che fa funzionare tutto il 202 processo. Contribuendo attraverso il vostro codice potete aggiungere nuove 203 funzioni al kernel e fornire competenze ed esempi che saranno utili ad 204 altri sviluppatori. Se avete sviluppato del codice Linux (o state pensando 205 di farlo), avete chiaramente interesse nel far proseguire il successo di 206 questa piattaforma. Contribuire al codice è une delle migliori vie per 207 aiutarne il successo. 208 209Il ragionamento sopra citato si applica ad ogni codice "fuori dai sorgenti" 210dal kernel, incluso il codice proprietario distribuito solamente in formato 211binario. Ci sono, comunque, dei fattori aggiuntivi che dovrebbero essere 212tenuti in conto prima di prendere in considerazione qualsiasi tipo di 213distribuzione binaria di codice kernel. Questo include che: 214 215- Le questioni legali legate alla distribuzione di moduli kernel proprietari 216 sono molto nebbiose; parecchi detentori di copyright sul kernel credono che 217 molti moduli binari siano prodotti derivati del kernel e che, come risultato, 218 la loro diffusione sia una violazione della licenza generale di GNU (della 219 quale si parlerà più avanti). L'autore qui non è un avvocato, e 220 niente in questo documento può essere considerato come un consiglio legale. 221 Il vero stato legale dei moduli proprietari può essere determinato 222 esclusivamente da un giudice. Ma l'incertezza che perseguita quei moduli 223 è lì comunque. 224 225- I moduli binari aumentano di molto la difficoltà di fare debugging del 226 kernel, al punto che la maggior parte degli sviluppatori del kernel non 227 vorranno nemmeno tentare. Quindi la diffusione di moduli esclusivamente 228 binari renderà difficile ai vostri utilizzatori trovare un supporto dalla 229 comunità. 230 231- Il supporto è anche difficile per i distributori di moduli binari che devono 232 fornire una versione del modulo per ogni distribuzione e per ogni versione 233 del kernel che vogliono supportate. Per fornire una copertura ragionevole e 234 comprensiva, può essere richiesto di produrre dozzine di singoli moduli. 235 E inoltre i vostri utilizzatori dovranno aggiornare il vostro modulo 236 separatamente ogni volta che aggiornano il loro kernel. 237 238- Tutto ciò che è stato detto prima riguardo alla revisione del codice si 239 applica doppiamente al codice proprietario. Dato che questo codice non è 240 del tutto disponibile, non può essere revisionato dalla comunità e avrà, 241 senza dubbio, seri problemi. 242 243I produttori di sistemi integrati, in particolare, potrebbero esser tentati 244dall'evitare molto di ciò che è stato detto in questa sezione, credendo che 245stiano distribuendo un prodotto finito che utilizza una versione del kernel 246immutabile e che non richiede un ulteriore sviluppo dopo il rilascio. Questa 247idea non comprende il valore di una vasta revisione del codice e il valore 248del permettere ai propri utenti di aggiungere funzionalità al vostro prodotto. 249Ma anche questi prodotti, hanno una vita commerciale limitata, dopo la quale 250deve essere rilasciata una nuova versione. A quel punto, i produttori il cui 251codice è nel ramo principale di sviluppo avranno un codice ben mantenuto e 252saranno in una posizione migliore per ottenere velocemente un nuovo prodotto 253pronto per essere distribuito. 254 255 256Licenza 257------- 258 259IL codice Linux utilizza diverse licenze, ma il codice completo deve essere 260compatibile con la seconda versione della licenza GNU General Public License 261(GPLv2), che è la licenza che copre la distribuzione del kernel. 262Nella pratica, ciò significa che tutti i contributi al codice sono coperti 263anche'essi dalla GPLv2 (con, opzionalmente, una dicitura che permette la 264possibilità di distribuirlo con licenze più recenti di GPL) o dalla licenza 265three-clause BSD. Qualsiasi contributo che non è coperto da una licenza 266compatibile non verrà accettata nel kernel. 267 268Per il codice sottomesso al kernel non è necessario (o richiesto) la 269concessione del Copyright. Tutto il codice inserito nel ramo principale del 270kernel conserva la sua proprietà originale; ne risulta che ora il kernel abbia 271migliaia di proprietari. 272 273Una conseguenza di questa organizzazione della proprietà è che qualsiasi 274tentativo di modifica della licenza del kernel è destinata ad un quasi sicuro 275fallimento. Esistono alcuni scenari pratici nei quali il consenso di tutti 276i detentori di copyright può essere ottenuto (o il loro codice verrà rimosso 277dal kernel). Quindi, in sostanza, non esiste la possibilità che si giunga ad 278una versione 3 della licenza GPL nel prossimo futuro. 279 280È imperativo che tutto il codice che contribuisce al kernel sia legittimamente 281software libero. Per questa ragione, un codice proveniente da un contributore 282anonimo (o sotto pseudonimo) non verrà accettato. È richiesto a tutti i 283contributori di firmare il proprio codice, attestando così che quest'ultimo 284può essere distribuito insieme al kernel sotto la licenza GPL. Il codice che 285non è stato licenziato come software libero dal proprio creatore, o che 286potrebbe creare problemi di copyright per il kernel (come il codice derivante 287da processi di ingegneria inversa senza le opportune tutele), non può essere 288diffuso. 289 290Domande relative a questioni legate al copyright sono frequenti nelle liste 291di discussione dedicate allo sviluppo di Linux. Tali quesiti, normalmente, 292non riceveranno alcuna risposta, ma una cosa deve essere tenuta presente: 293le persone che risponderanno a quelle domande non sono avvocati e non possono 294fornire supporti legali. Se avete questioni legali relative ai sorgenti 295del codice Linux, non esiste alternativa che quella di parlare con un 296avvocato esperto nel settore. Fare affidamento sulle risposte ottenute da 297una lista di discussione tecnica è rischioso.