298 lines · plain
1.. include:: ../disclaimer-ita.rst2 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 8Introduzione9============10 11Riepilogo generale12------------------13 14Il resto di questa sezione riguarda il processo di sviluppo del kernel e15quella sorta di frustrazione che gli sviluppatori e i loro datori di lavoro16potrebbero dover affrontare. Ci sono molte ragioni per le quali del codice17per il kernel debba essere incorporato nel kernel ufficiale, fra le quali:18disponibilità immediata agli utilizzatori, supporto della comunità in19differenti modalità, e la capacità di influenzare la direzione dello sviluppo20del kernel.21Il codice che contribuisce al kernel Linux deve essere reso disponibile sotto22una 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 finestra26d'incorporazione. Il capitolo copre le varie fasi di una modifica: sviluppo,27revisione e ciclo d'incorporazione. Ci sono alcuni dibattiti su strumenti e28liste di discussione. Gli sviluppatori che sono in attesa di poter sviluppare29qualcosa per il kernel sono invitati ad individuare e sistemare bachi come30esercizio iniziale.31 32La sezione :ref:`it_development_early_stage` copre i primi stadi della33pianificazione di un progetto di sviluppo, con particolare enfasi sul34coinvolgimento della comunità, il prima possibile.35 36La sezione :ref:`it_development_coding` riguarda il processo di scrittura37del codice. Qui, sono esposte le diverse insidie che sono state già affrontate38da altri sviluppatori. Il capitolo copre anche alcuni dei requisiti per le39modifiche, ed esiste un'introduzione ad alcuni strumenti che possono aiutarvi40nell'assicurarvi che le modifiche per il kernel siano corrette.41 42La sezione :ref:`it_development_posting` parla del processo di pubblicazione43delle modifiche per la revisione. Per essere prese in considerazione dalla44comunità di sviluppo, le modifiche devono essere propriamente formattate ed45esposte, e devono essere inviate nel posto giusto. Seguire i consigli presenti46in questa sezione dovrebbe essere d'aiuto nell'assicurare la migliore47accoglienza possibile del vostro lavoro.48 49La sezione :ref:`it_development_followthrough` copre ciò che accade dopo50la pubblicazione delle modifiche; a questo punto il lavoro è lontano51dall'essere concluso. Lavorare con i revisori è una parte cruciale del52processo di sviluppo; questa sezione offre una serie di consigli su come53evitare problemi in questa importante fase. Gli sviluppatori sono diffidenti54nell'affermare che il lavoro è concluso quando una modifica è incorporata nei55sorgenti principali.56 57La sezione :ref:`it_development_advancedtopics` introduce un paio di argomenti58"avanzati": gestire le modifiche con git e controllare le modifiche pubblicate59da altri.60 61La sezione :ref:`it_development_conclusion` chiude il documento con dei62riferimenti ad altre fonti che forniscono ulteriori informazioni sullo sviluppo63del kernel.64 65Di cosa parla questo documento66------------------------------67 68Il kernel Linux, ha oltre 8 milioni di linee di codice e ben oltre 100069contributori ad ogni rilascio; è uno dei più vasti e più attivi software70liberi progettati mai esistiti. Sin dal sul modesto inizio nel 1991,71questo kernel si è evoluto nel miglior componente per sistemi operativi72che fanno funzionare piccoli riproduttori musicali, PC, grandi super computer73e tutte le altre tipologie di sistemi fra questi estremi. È una soluzione74robusta, efficiente ed adattabile a praticamente qualsiasi situazione.75 76Con la crescita di Linux è arrivato anche un aumento di sviluppatori77(ed aziende) desiderosi di partecipare a questo sviluppo. I produttori di78hardware vogliono assicurarsi che il loro prodotti siano supportati da Linux,79rendendo questi prodotti attrattivi agli utenti Linux. I produttori di80sistemi integrati, che usano Linux come componente di un prodotto integrato,81vogliono che Linux sia capace ed adeguato agli obiettivi ed il più possibile82alla mano. Fornitori ed altri produttori di software che basano i propri83prodotti su Linux hanno un chiaro interesse verso capacità, prestazioni ed84affidabilità del kernel Linux. E gli utenti finali, anche, spesso vorrebbero85cambiare 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ò migliorare89Linux ed influenzarne la direzione di sviluppo. Prodotti non open-source non90possono offrire questo tipo di apertura, che è una caratteristica del software91libero. Ma, anzi, il kernel è persino più aperto rispetto a molti altri92progetti di software libero. Un classico ciclo di sviluppo trimestrale può93coinvolgere 1000 sviluppatori che lavorano per più di 100 differenti aziende94(o per nessuna azienda).95 96Lavorare con la comunità di sviluppo del kernel non è particolarmente97difficile. Ma, ciononostante, diversi potenziali contributori hanno trovato98delle difficoltà quando hanno cercato di lavorare sul kernel. La comunità del99kernel utilizza un proprio modo di operare che gli permette di funzionare100agevolmente (e genera un prodotto di alta qualità) in un ambiente dove migliaia101di stringhe di codice sono modificate ogni giorni. Quindi non deve sorprendere102che il processo di sviluppo del kernel differisca notevolmente dai metodi di103sviluppo privati.104 105Il processo di sviluppo del Kernel può, dall'altro lato, risultare106intimidatorio e strano ai nuovi sviluppatori, ma ha dietro di se buone ragioni107e solide esperienze. Uno sviluppatore che non comprende i modi della comunità108del kernel (o, peggio, che cerchi di aggirarli o violarli) avrà un'esperienza109deludente nel proprio bagaglio. La comunità di sviluppo, sebbene sia utile110a coloro che cercano di imparare, ha poco tempo da dedicare a coloro che non111ascoltano o coloro che non sono interessati al processo di sviluppo.112 113Si spera che coloro che leggono questo documento saranno in grado di evitare114queste esperienze spiacevoli. C'è molto materiale qui, ma lo sforzo della115lettura sarà ripagato in breve tempo. La comunità di sviluppo ha sempre116bisogno di sviluppatori che vogliano aiutare a rendere il kernel migliore;117il testo seguente potrebbe esservi d'aiuto - o essere d'aiuto ai vostri118collaboratori- per entrare a far parte della nostra comunità.119 120Crediti121-------122 123Questo documento è stato scritto da Jonathan Corbet, corbet@lwn.net.124È stato migliorato da Johannes Berg, James Berry, Alex Chiang, Roland125Dreier, 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 ringraziamento129speciale ad Amanda McPherson, che ha visto il valore di questo lavoro e lo ha130reso possibile.131 132L'importanza d'avere il codice nei sorgenti principali133------------------------------------------------------134 135Alcune aziende e sviluppatori ogni tanto si domandano perché dovrebbero136preoccuparsi di apprendere come lavorare con la comunità del kernel e di137inserire il loro codice nel ramo di sviluppo principale (per ramo principale138s'intende quello mantenuto da Linus Torvalds e usato come base dai139distributori Linux). Nel breve termine, contribuire al codice può sembrare140un costo inutile; può sembra più facile tenere separato il proprio codice e141supportare direttamente i suoi utilizzatori. La verità è che il tenere il142codice separato ("fuori dai sorgenti", *"out-of-tree"*) è un falso risparmio.143 144Per dimostrare i costi di un codice "fuori dai sorgenti", eccovi145alcuni aspetti rilevanti del processo di sviluppo kernel; la maggior parte146di essi saranno approfonditi dettagliatamente più avanti in questo documento.147Considerate:148 149- Il codice che è stato inserito nel ramo principale del kernel è disponibile150 a tutti gli utilizzatori Linux. Sarà automaticamente presente in tutte le151 distribuzioni che lo consentono. Non c'è bisogno di: driver per dischi,152 scaricare file, o della scocciatura del dover supportare diverse versioni di153 diverse distribuzioni; funziona già tutto, per gli sviluppatori e per gli154 utilizzatori. L'inserimento nel ramo principale risolve un gran numero di155 problemi di distribuzione e di supporto.156 157- Nonostante gli sviluppatori kernel si sforzino di tenere stabile158 l'interfaccia dello spazio utente, quella interna al kernel è in continuo159 cambiamento. La mancanza di un'interfaccia interna è deliberatamente una160 decisione di progettazione; ciò permette che i miglioramenti fondamentali161 vengano fatti in un qualsiasi momento e che risultino fatti con un codice di162 alta qualità. Ma una delle conseguenze di questa politica è che qualsiasi163 codice "fuori dai sorgenti" richiede costante manutenzione per renderlo164 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 questo168 tipo di lavoro poiché ad ogni sviluppatore che faccia una modifica alle169 interfacce viene richiesto di sistemare anche il codice che utilizza170 quell'interfaccia. Quindi, il codice che è stato inserito nel ramo principale171 ha dei costi di mantenimento significativamente più bassi.172 173- Oltre a ciò, spesso il codice che è all'interno del kernel sarà migliorato da174 altri sviluppatori. Dare pieni poteri alla vostra comunità di utenti e ai175 clienti può portare a sorprendenti risultati che migliorano i vostri176 prodotti.177 178- Il codice kernel è soggetto a revisioni, sia prima che dopo l'inserimento179 nel ramo principale. Non importa quanto forti fossero le abilità dello180 sviluppatore originale, il processo di revisione troverà il modo di migliore181 il codice. Spesso la revisione trova bachi importanti e problemi di182 sicurezza. Questo è particolarmente vero per il codice che è stato183 sviluppato in un ambiente chiuso; tale codice ottiene un forte beneficio184 dalle revisioni provenienti da sviluppatori esteri. Il codice185 "fuori dai sorgenti", invece, è un codice di bassa qualità.186 187- La partecipazione al processo di sviluppo costituisce la vostra via per188 influenzare la direzione di sviluppo del kernel. Gli utilizzatori che189 "reclamano da bordo campo" sono ascoltati, ma gli sviluppatori attivi190 hanno una voce più forte - e la capacità di implementare modifiche che191 renderanno il kernel più funzionale alle loro necessità.192 193- Quando il codice è gestito separatamente, esiste sempre la possibilità che194 terze parti contribuiscano con una differente implementazione che fornisce195 le stesse funzionalità. Se dovesse accadere, l'inserimento del codice196 diventerà molto più difficile - fino all'impossibilità. Poi, dovrete far197 fronte a delle alternative poco piacevoli, come: (1) mantenere un elemento198 non standard "fuori dai sorgenti" per un tempo indefinito, o (2) abbandonare199 il codice e far migrare i vostri utenti alla versione "nei sorgenti".200 201- Contribuire al codice è l'azione fondamentale che fa funzionare tutto il202 processo. Contribuendo attraverso il vostro codice potete aggiungere nuove203 funzioni al kernel e fornire competenze ed esempi che saranno utili ad204 altri sviluppatori. Se avete sviluppato del codice Linux (o state pensando205 di farlo), avete chiaramente interesse nel far proseguire il successo di206 questa piattaforma. Contribuire al codice è une delle migliori vie per207 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 formato211binario. Ci sono, comunque, dei fattori aggiuntivi che dovrebbero essere212tenuti in conto prima di prendere in considerazione qualsiasi tipo di213distribuzione binaria di codice kernel. Questo include che:214 215- Le questioni legali legate alla distribuzione di moduli kernel proprietari216 sono molto nebbiose; parecchi detentori di copyright sul kernel credono che217 molti moduli binari siano prodotti derivati del kernel e che, come risultato,218 la loro diffusione sia una violazione della licenza generale di GNU (della219 quale si parlerà più avanti). L'autore qui non è un avvocato, e220 niente in questo documento può essere considerato come un consiglio legale.221 Il vero stato legale dei moduli proprietari può essere determinato222 esclusivamente da un giudice. Ma l'incertezza che perseguita quei moduli223 è lì comunque.224 225- I moduli binari aumentano di molto la difficoltà di fare debugging del226 kernel, al punto che la maggior parte degli sviluppatori del kernel non227 vorranno nemmeno tentare. Quindi la diffusione di moduli esclusivamente228 binari renderà difficile ai vostri utilizzatori trovare un supporto dalla229 comunità.230 231- Il supporto è anche difficile per i distributori di moduli binari che devono232 fornire una versione del modulo per ogni distribuzione e per ogni versione233 del kernel che vogliono supportate. Per fornire una copertura ragionevole e234 comprensiva, può essere richiesto di produrre dozzine di singoli moduli.235 E inoltre i vostri utilizzatori dovranno aggiornare il vostro modulo236 separatamente ogni volta che aggiornano il loro kernel.237 238- Tutto ciò che è stato detto prima riguardo alla revisione del codice si239 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 tentati244dall'evitare molto di ciò che è stato detto in questa sezione, credendo che245stiano distribuendo un prodotto finito che utilizza una versione del kernel246immutabile e che non richiede un ulteriore sviluppo dopo il rilascio. Questa247idea non comprende il valore di una vasta revisione del codice e il valore248del permettere ai propri utenti di aggiungere funzionalità al vostro prodotto.249Ma anche questi prodotti, hanno una vita commerciale limitata, dopo la quale250deve essere rilasciata una nuova versione. A quel punto, i produttori il cui251codice è nel ramo principale di sviluppo avranno un codice ben mantenuto e252saranno in una posizione migliore per ottenere velocemente un nuovo prodotto253pronto per essere distribuito.254 255 256Licenza257-------258 259IL codice Linux utilizza diverse licenze, ma il codice completo deve essere260compatibile con la seconda versione della licenza GNU General Public License261(GPLv2), che è la licenza che copre la distribuzione del kernel.262Nella pratica, ciò significa che tutti i contributi al codice sono coperti263anche'essi dalla GPLv2 (con, opzionalmente, una dicitura che permette la264possibilità di distribuirlo con licenze più recenti di GPL) o dalla licenza265three-clause BSD. Qualsiasi contributo che non è coperto da una licenza266compatibile non verrà accettata nel kernel.267 268Per il codice sottomesso al kernel non è necessario (o richiesto) la269concessione del Copyright. Tutto il codice inserito nel ramo principale del270kernel conserva la sua proprietà originale; ne risulta che ora il kernel abbia271migliaia di proprietari.272 273Una conseguenza di questa organizzazione della proprietà è che qualsiasi274tentativo di modifica della licenza del kernel è destinata ad un quasi sicuro275fallimento. Esistono alcuni scenari pratici nei quali il consenso di tutti276i detentori di copyright può essere ottenuto (o il loro codice verrà rimosso277dal kernel). Quindi, in sostanza, non esiste la possibilità che si giunga ad278una versione 3 della licenza GPL nel prossimo futuro.279 280È imperativo che tutto il codice che contribuisce al kernel sia legittimamente281software libero. Per questa ragione, un codice proveniente da un contributore282anonimo (o sotto pseudonimo) non verrà accettato. È richiesto a tutti i283contributori di firmare il proprio codice, attestando così che quest'ultimo284può essere distribuito insieme al kernel sotto la licenza GPL. Il codice che285non è stato licenziato come software libero dal proprio creatore, o che286potrebbe creare problemi di copyright per il kernel (come il codice derivante287da processi di ingegneria inversa senza le opportune tutele), non può essere288diffuso.289 290Domande relative a questioni legate al copyright sono frequenti nelle liste291di 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 possono294fornire supporti legali. Se avete questioni legali relative ai sorgenti295del codice Linux, non esiste alternativa che quella di parlare con un296avvocato esperto nel settore. Fare affidamento sulle risposte ottenute da297una lista di discussione tecnica è rischioso.298