0001 .. include:: ../disclaimer-ita.rst
0002
0003 :Original: :ref:`Documentation/process/1.Intro.rst <development_process_intro>`
0004 :Translator: Alessia Mantegazza <amantegazza@vaga.pv.it>
0005
0006 .. _it_development_intro:
0007
0008 Introduzione
0009 ============
0010
0011 Riepilogo generale
0012 ------------------
0013
0014 Il resto di questa sezione riguarda il processo di sviluppo del kernel e
0015 quella sorta di frustrazione che gli sviluppatori e i loro datori di lavoro
0016 potrebbero dover affrontare. Ci sono molte ragioni per le quali del codice
0017 per il kernel debba essere incorporato nel kernel ufficiale, fra le quali:
0018 disponibilità immediata agli utilizzatori, supporto della comunità in
0019 differenti modalità, e la capacità di influenzare la direzione dello sviluppo
0020 del kernel.
0021 Il codice che contribuisce al kernel Linux deve essere reso disponibile sotto
0022 una licenza GPL-compatibile.
0023
0024 La sezione :ref:`it_development_process` introduce il processo di sviluppo,
0025 il ciclo di rilascio del kernel, ed i meccanismi della finestra
0026 d'incorporazione. Il capitolo copre le varie fasi di una modifica: sviluppo,
0027 revisione e ciclo d'incorporazione. Ci sono alcuni dibattiti su strumenti e
0028 liste di discussione. Gli sviluppatori che sono in attesa di poter sviluppare
0029 qualcosa per il kernel sono invitati ad individuare e sistemare bachi come
0030 esercizio iniziale.
0031
0032 La sezione :ref:`it_development_early_stage` copre i primi stadi della
0033 pianificazione di un progetto di sviluppo, con particolare enfasi sul
0034 coinvolgimento della comunità, il prima possibile.
0035
0036 La sezione :ref:`it_development_coding` riguarda il processo di scrittura
0037 del codice. Qui, sono esposte le diverse insidie che sono state già affrontate
0038 da altri sviluppatori. Il capitolo copre anche alcuni dei requisiti per le
0039 modifiche, ed esiste un'introduzione ad alcuni strumenti che possono aiutarvi
0040 nell'assicurarvi che le modifiche per il kernel siano corrette.
0041
0042 La sezione :ref:`it_development_posting` parla del processo di pubblicazione
0043 delle modifiche per la revisione. Per essere prese in considerazione dalla
0044 comunità di sviluppo, le modifiche devono essere propriamente formattate ed
0045 esposte, e devono essere inviate nel posto giusto. Seguire i consigli presenti
0046 in questa sezione dovrebbe essere d'aiuto nell'assicurare la migliore
0047 accoglienza possibile del vostro lavoro.
0048
0049 La sezione :ref:`it_development_followthrough` copre ciò che accade dopo
0050 la pubblicazione delle modifiche; a questo punto il lavoro è lontano
0051 dall'essere concluso. Lavorare con i revisori è una parte cruciale del
0052 processo di sviluppo; questa sezione offre una serie di consigli su come
0053 evitare problemi in questa importante fase. Gli sviluppatori sono diffidenti
0054 nell'affermare che il lavoro è concluso quando una modifica è incorporata nei
0055 sorgenti principali.
0056
0057 La sezione :ref:`it_development_advancedtopics` introduce un paio di argomenti
0058 "avanzati": gestire le modifiche con git e controllare le modifiche pubblicate
0059 da altri.
0060
0061 La sezione :ref:`it_development_conclusion` chiude il documento con dei
0062 riferimenti ad altre fonti che forniscono ulteriori informazioni sullo sviluppo
0063 del kernel.
0064
0065 Di cosa parla questo documento
0066 ------------------------------
0067
0068 Il kernel Linux, ha oltre 8 milioni di linee di codice e ben oltre 1000
0069 contributori ad ogni rilascio; è uno dei più vasti e più attivi software
0070 liberi progettati mai esistiti. Sin dal sul modesto inizio nel 1991,
0071 questo kernel si è evoluto nel miglior componente per sistemi operativi
0072 che fanno funzionare piccoli riproduttori musicali, PC, grandi super computer
0073 e tutte le altre tipologie di sistemi fra questi estremi. È una soluzione
0074 robusta, efficiente ed adattabile a praticamente qualsiasi situazione.
0075
0076 Con la crescita di Linux è arrivato anche un aumento di sviluppatori
0077 (ed aziende) desiderosi di partecipare a questo sviluppo. I produttori di
0078 hardware vogliono assicurarsi che il loro prodotti siano supportati da Linux,
0079 rendendo questi prodotti attrattivi agli utenti Linux. I produttori di
0080 sistemi integrati, che usano Linux come componente di un prodotto integrato,
0081 vogliono che Linux sia capace ed adeguato agli obiettivi ed il più possibile
0082 alla mano. Fornitori ed altri produttori di software che basano i propri
0083 prodotti su Linux hanno un chiaro interesse verso capacità, prestazioni ed
0084 affidabilità del kernel Linux. E gli utenti finali, anche, spesso vorrebbero
0085 cambiare Linux per renderlo più aderente alle proprie necessità.
0086
0087 Una delle caratteristiche più coinvolgenti di Linux è quella dell'accessibilità
0088 per gli sviluppatori; chiunque con le capacità richieste può migliorare
0089 Linux ed influenzarne la direzione di sviluppo. Prodotti non open-source non
0090 possono offrire questo tipo di apertura, che è una caratteristica del software
0091 libero. Ma, anzi, il kernel è persino più aperto rispetto a molti altri
0092 progetti di software libero. Un classico ciclo di sviluppo trimestrale può
0093 coinvolgere 1000 sviluppatori che lavorano per più di 100 differenti aziende
0094 (o per nessuna azienda).
0095
0096 Lavorare con la comunità di sviluppo del kernel non è particolarmente
0097 difficile. Ma, ciononostante, diversi potenziali contributori hanno trovato
0098 delle difficoltà quando hanno cercato di lavorare sul kernel. La comunità del
0099 kernel utilizza un proprio modo di operare che gli permette di funzionare
0100 agevolmente (e genera un prodotto di alta qualità) in un ambiente dove migliaia
0101 di stringhe di codice sono modificate ogni giorni. Quindi non deve sorprendere
0102 che il processo di sviluppo del kernel differisca notevolmente dai metodi di
0103 sviluppo privati.
0104
0105 Il processo di sviluppo del Kernel può, dall'altro lato, risultare
0106 intimidatorio e strano ai nuovi sviluppatori, ma ha dietro di se buone ragioni
0107 e solide esperienze. Uno sviluppatore che non comprende i modi della comunità
0108 del kernel (o, peggio, che cerchi di aggirarli o violarli) avrà un'esperienza
0109 deludente nel proprio bagaglio. La comunità di sviluppo, sebbene sia utile
0110 a coloro che cercano di imparare, ha poco tempo da dedicare a coloro che non
0111 ascoltano o coloro che non sono interessati al processo di sviluppo.
0112
0113 Si spera che coloro che leggono questo documento saranno in grado di evitare
0114 queste esperienze spiacevoli. C'è molto materiale qui, ma lo sforzo della
0115 lettura sarà ripagato in breve tempo. La comunità di sviluppo ha sempre
0116 bisogno di sviluppatori che vogliano aiutare a rendere il kernel migliore;
0117 il testo seguente potrebbe esservi d'aiuto - o essere d'aiuto ai vostri
0118 collaboratori- per entrare a far parte della nostra comunità.
0119
0120 Crediti
0121 -------
0122
0123 Questo documento è stato scritto da Jonathan Corbet, corbet@lwn.net.
0124 È stato migliorato da Johannes Berg, James Berry, Alex Chiang, Roland
0125 Dreier, Randy Dunlap, Jake Edge, Jiri Kosina, Matt Mackall, Arthur Marsh,
0126 Amanda McPherson, Andrew Morton, Andrew Price, Tsugikazu Shibata e Jochen Voß.
0127
0128 Questo lavoro è stato supportato dalla Linux Foundation; un ringraziamento
0129 speciale ad Amanda McPherson, che ha visto il valore di questo lavoro e lo ha
0130 reso possibile.
0131
0132 L'importanza d'avere il codice nei sorgenti principali
0133 ------------------------------------------------------
0134
0135 Alcune aziende e sviluppatori ogni tanto si domandano perché dovrebbero
0136 preoccuparsi di apprendere come lavorare con la comunità del kernel e di
0137 inserire il loro codice nel ramo di sviluppo principale (per ramo principale
0138 s'intende quello mantenuto da Linus Torvalds e usato come base dai
0139 distributori Linux). Nel breve termine, contribuire al codice può sembrare
0140 un costo inutile; può sembra più facile tenere separato il proprio codice e
0141 supportare direttamente i suoi utilizzatori. La verità è che il tenere il
0142 codice separato ("fuori dai sorgenti", *"out-of-tree"*) è un falso risparmio.
0143
0144 Per dimostrare i costi di un codice "fuori dai sorgenti", eccovi
0145 alcuni aspetti rilevanti del processo di sviluppo kernel; la maggior parte
0146 di essi saranno approfonditi dettagliatamente più avanti in questo documento.
0147 Considerate:
0148
0149 - Il codice che è stato inserito nel ramo principale del kernel è disponibile
0150 a tutti gli utilizzatori Linux. Sarà automaticamente presente in tutte le
0151 distribuzioni che lo consentono. Non c'è bisogno di: driver per dischi,
0152 scaricare file, o della scocciatura del dover supportare diverse versioni di
0153 diverse distribuzioni; funziona già tutto, per gli sviluppatori e per gli
0154 utilizzatori. L'inserimento nel ramo principale risolve un gran numero di
0155 problemi di distribuzione e di supporto.
0156
0157 - Nonostante gli sviluppatori kernel si sforzino di tenere stabile
0158 l'interfaccia dello spazio utente, quella interna al kernel è in continuo
0159 cambiamento. La mancanza di un'interfaccia interna è deliberatamente una
0160 decisione di progettazione; ciò permette che i miglioramenti fondamentali
0161 vengano fatti in un qualsiasi momento e che risultino fatti con un codice di
0162 alta qualità. Ma una delle conseguenze di questa politica è che qualsiasi
0163 codice "fuori dai sorgenti" richiede costante manutenzione per renderlo
0164 funzionante coi kernel più recenti. Tenere un codice "fuori dai sorgenti"
0165 richiede una mole di lavoro significativa solo per farlo funzionare.
0166
0167 Invece, il codice che si trova nel ramo principale non necessita di questo
0168 tipo di lavoro poiché ad ogni sviluppatore che faccia una modifica alle
0169 interfacce viene richiesto di sistemare anche il codice che utilizza
0170 quell'interfaccia. Quindi, il codice che è stato inserito nel ramo principale
0171 ha dei costi di mantenimento significativamente più bassi.
0172
0173 - Oltre a ciò, spesso il codice che è all'interno del kernel sarà migliorato da
0174 altri sviluppatori. Dare pieni poteri alla vostra comunità di utenti e ai
0175 clienti può portare a sorprendenti risultati che migliorano i vostri
0176 prodotti.
0177
0178 - Il codice kernel è soggetto a revisioni, sia prima che dopo l'inserimento
0179 nel ramo principale. Non importa quanto forti fossero le abilità dello
0180 sviluppatore originale, il processo di revisione troverà il modo di migliore
0181 il codice. Spesso la revisione trova bachi importanti e problemi di
0182 sicurezza. Questo è particolarmente vero per il codice che è stato
0183 sviluppato in un ambiente chiuso; tale codice ottiene un forte beneficio
0184 dalle revisioni provenienti da sviluppatori esteri. Il codice
0185 "fuori dai sorgenti", invece, è un codice di bassa qualità.
0186
0187 - La partecipazione al processo di sviluppo costituisce la vostra via per
0188 influenzare la direzione di sviluppo del kernel. Gli utilizzatori che
0189 "reclamano da bordo campo" sono ascoltati, ma gli sviluppatori attivi
0190 hanno una voce più forte - e la capacità di implementare modifiche che
0191 renderanno il kernel più funzionale alle loro necessità.
0192
0193 - Quando il codice è gestito separatamente, esiste sempre la possibilità che
0194 terze parti contribuiscano con una differente implementazione che fornisce
0195 le stesse funzionalità. Se dovesse accadere, l'inserimento del codice
0196 diventerà molto più difficile - fino all'impossibilità. Poi, dovrete far
0197 fronte a delle alternative poco piacevoli, come: (1) mantenere un elemento
0198 non standard "fuori dai sorgenti" per un tempo indefinito, o (2) abbandonare
0199 il codice e far migrare i vostri utenti alla versione "nei sorgenti".
0200
0201 - Contribuire al codice è l'azione fondamentale che fa funzionare tutto il
0202 processo. Contribuendo attraverso il vostro codice potete aggiungere nuove
0203 funzioni al kernel e fornire competenze ed esempi che saranno utili ad
0204 altri sviluppatori. Se avete sviluppato del codice Linux (o state pensando
0205 di farlo), avete chiaramente interesse nel far proseguire il successo di
0206 questa piattaforma. Contribuire al codice è une delle migliori vie per
0207 aiutarne il successo.
0208
0209 Il ragionamento sopra citato si applica ad ogni codice "fuori dai sorgenti"
0210 dal kernel, incluso il codice proprietario distribuito solamente in formato
0211 binario. Ci sono, comunque, dei fattori aggiuntivi che dovrebbero essere
0212 tenuti in conto prima di prendere in considerazione qualsiasi tipo di
0213 distribuzione binaria di codice kernel. Questo include che:
0214
0215 - Le questioni legali legate alla distribuzione di moduli kernel proprietari
0216 sono molto nebbiose; parecchi detentori di copyright sul kernel credono che
0217 molti moduli binari siano prodotti derivati del kernel e che, come risultato,
0218 la loro diffusione sia una violazione della licenza generale di GNU (della
0219 quale si parlerà più avanti). L'autore qui non è un avvocato, e
0220 niente in questo documento può essere considerato come un consiglio legale.
0221 Il vero stato legale dei moduli proprietari può essere determinato
0222 esclusivamente da un giudice. Ma l'incertezza che perseguita quei moduli
0223 è lì comunque.
0224
0225 - I moduli binari aumentano di molto la difficoltà di fare debugging del
0226 kernel, al punto che la maggior parte degli sviluppatori del kernel non
0227 vorranno nemmeno tentare. Quindi la diffusione di moduli esclusivamente
0228 binari renderà difficile ai vostri utilizzatori trovare un supporto dalla
0229 comunità.
0230
0231 - Il supporto è anche difficile per i distributori di moduli binari che devono
0232 fornire una versione del modulo per ogni distribuzione e per ogni versione
0233 del kernel che vogliono supportate. Per fornire una copertura ragionevole e
0234 comprensiva, può essere richiesto di produrre dozzine di singoli moduli.
0235 E inoltre i vostri utilizzatori dovranno aggiornare il vostro modulo
0236 separatamente ogni volta che aggiornano il loro kernel.
0237
0238 - Tutto ciò che è stato detto prima riguardo alla revisione del codice si
0239 applica doppiamente al codice proprietario. Dato che questo codice non è
0240 del tutto disponibile, non può essere revisionato dalla comunità e avrà,
0241 senza dubbio, seri problemi.
0242
0243 I produttori di sistemi integrati, in particolare, potrebbero esser tentati
0244 dall'evitare molto di ciò che è stato detto in questa sezione, credendo che
0245 stiano distribuendo un prodotto finito che utilizza una versione del kernel
0246 immutabile e che non richiede un ulteriore sviluppo dopo il rilascio. Questa
0247 idea non comprende il valore di una vasta revisione del codice e il valore
0248 del permettere ai propri utenti di aggiungere funzionalità al vostro prodotto.
0249 Ma anche questi prodotti, hanno una vita commerciale limitata, dopo la quale
0250 deve essere rilasciata una nuova versione. A quel punto, i produttori il cui
0251 codice è nel ramo principale di sviluppo avranno un codice ben mantenuto e
0252 saranno in una posizione migliore per ottenere velocemente un nuovo prodotto
0253 pronto per essere distribuito.
0254
0255
0256 Licenza
0257 -------
0258
0259 IL codice Linux utilizza diverse licenze, ma il codice completo deve essere
0260 compatibile con la seconda versione della licenza GNU General Public License
0261 (GPLv2), che è la licenza che copre la distribuzione del kernel.
0262 Nella pratica, ciò significa che tutti i contributi al codice sono coperti
0263 anche'essi dalla GPLv2 (con, opzionalmente, una dicitura che permette la
0264 possibilità di distribuirlo con licenze più recenti di GPL) o dalla licenza
0265 three-clause BSD. Qualsiasi contributo che non è coperto da una licenza
0266 compatibile non verrà accettata nel kernel.
0267
0268 Per il codice sottomesso al kernel non è necessario (o richiesto) la
0269 concessione del Copyright. Tutto il codice inserito nel ramo principale del
0270 kernel conserva la sua proprietà originale; ne risulta che ora il kernel abbia
0271 migliaia di proprietari.
0272
0273 Una conseguenza di questa organizzazione della proprietà è che qualsiasi
0274 tentativo di modifica della licenza del kernel è destinata ad un quasi sicuro
0275 fallimento. Esistono alcuni scenari pratici nei quali il consenso di tutti
0276 i detentori di copyright può essere ottenuto (o il loro codice verrà rimosso
0277 dal kernel). Quindi, in sostanza, non esiste la possibilità che si giunga ad
0278 una versione 3 della licenza GPL nel prossimo futuro.
0279
0280 È imperativo che tutto il codice che contribuisce al kernel sia legittimamente
0281 software libero. Per questa ragione, un codice proveniente da un contributore
0282 anonimo (o sotto pseudonimo) non verrà accettato. È richiesto a tutti i
0283 contributori di firmare il proprio codice, attestando così che quest'ultimo
0284 può essere distribuito insieme al kernel sotto la licenza GPL. Il codice che
0285 non è stato licenziato come software libero dal proprio creatore, o che
0286 potrebbe creare problemi di copyright per il kernel (come il codice derivante
0287 da processi di ingegneria inversa senza le opportune tutele), non può essere
0288 diffuso.
0289
0290 Domande relative a questioni legate al copyright sono frequenti nelle liste
0291 di discussione dedicate allo sviluppo di Linux. Tali quesiti, normalmente,
0292 non riceveranno alcuna risposta, ma una cosa deve essere tenuta presente:
0293 le persone che risponderanno a quelle domande non sono avvocati e non possono
0294 fornire supporti legali. Se avete questioni legali relative ai sorgenti
0295 del codice Linux, non esiste alternativa che quella di parlare con un
0296 avvocato esperto nel settore. Fare affidamento sulle risposte ottenute da
0297 una lista di discussione tecnica è rischioso.
