| blob | c1be6dc398a79b9f6fd53e6f46484fd1c5cdd610 |
1 .. include:: ../disclaimer-ita.rst
3 :Original: :ref:`Documentation/process/1.Intro.rst <development_process_intro>`
4 :Translator: Alessia Mantegazza <amantegazza@vaga.pv.it>
6 .. _it_development_intro:
8 Introduzione
9 ============
11 Riepilogo generale
12 ------------------
14 Il resto di questa sezione riguarda il processo di sviluppo del kernel e
15 quella sorta di frustrazione che gli sviluppatori e i loro datori di lavoro
16 potrebbero dover affrontare. Ci sono molte ragioni per le quali del codice
17 per il kernel debba essere incorporato nel kernel ufficiale, fra le quali:
18 disponibilità immediata agli utilizzatori, supporto della comunità in
19 differenti modalità, e la capacità di influenzare la direzione dello sviluppo
20 del kernel.
21 Il codice che contribuisce al kernel Linux deve essere reso disponibile sotto
22 una licenza GPL-compatibile.
24 La sezione :ref:`it_development_process` introduce il processo di sviluppo,
25 il ciclo di rilascio del kernel, ed i meccanismi della finestra
26 d'incorporazione. Il capitolo copre le varie fasi di una modifica: sviluppo,
27 revisione e ciclo d'incorporazione. Ci sono alcuni dibattiti su strumenti e
28 liste di discussione. Gli sviluppatori che sono in attesa di poter sviluppare
29 qualcosa per il kernel sono invitati ad individuare e sistemare bachi come
30 esercizio iniziale.
32 La sezione :ref:`it_development_early_stage` copre i primi stadi della
33 pianificazione di un progetto di sviluppo, con particolare enfasi sul
34 coinvolgimento della comunità, il prima possibile.
36 La sezione :ref:`it_development_coding` riguarda il processo di scrittura
37 del codice. Qui, sono esposte le diverse insidie che sono state già affrontate
38 da altri sviluppatori. Il capitolo copre anche alcuni dei requisiti per le
39 modifiche, ed esiste un'introduzione ad alcuni strumenti che possono aiutarvi
40 nell'assicurarvi che le modifiche per il kernel siano corrette.
42 La sezione :ref:`it_development_posting` parla del processo di pubblicazione
43 delle modifiche per la revisione. Per essere prese in considerazione dalla
44 comunità di sviluppo, le modifiche devono essere propriamente formattate ed
45 esposte, e devono essere inviate nel posto giusto. Seguire i consigli presenti
46 in questa sezione dovrebbe essere d'aiuto nell'assicurare la migliore
47 accoglienza possibile del vostro lavoro.
49 La sezione :ref:`it_development_followthrough` copre ciò che accade dopo
50 la pubblicazione delle modifiche; a questo punto il lavoro è lontano
51 dall'essere concluso. Lavorare con i revisori è una parte cruciale del
52 processo di sviluppo; questa sezione offre una serie di consigli su come
53 evitare problemi in questa importante fase. Gli sviluppatori sono diffidenti
54 nell'affermare che il lavoro è concluso quando una modifica è incorporata nei
55 sorgenti principali.
57 La sezione :ref:`it_development_advancedtopics` introduce un paio di argomenti
58 "avanzati": gestire le modifiche con git e controllare le modifiche pubblicate
59 da altri.
61 La sezione :ref:`it_development_conclusion` chiude il documento con dei
62 riferimenti ad altre fonti che forniscono ulteriori informazioni sullo sviluppo
63 del kernel.
65 Di cosa parla questo documento
66 ------------------------------
68 Il kernel Linux, ha oltre 8 milioni di linee di codice e ben oltre 1000
69 contributori ad ogni rilascio; è uno dei più vasti e più attivi software
70 liberi progettati mai esistiti. Sin dal sul modesto inizio nel 1991,
71 questo kernel si è evoluto nel miglior componente per sistemi operativi
72 che fanno funzionare piccoli riproduttori musicali, PC, grandi super computer
73 e tutte le altre tipologie di sistemi fra questi estremi. È una soluzione
74 robusta, efficiente ed adattabile a praticamente qualsiasi situazione.
76 Con la crescita di Linux è arrivato anche un aumento di sviluppatori
77 (ed aziende) desiderosi di partecipare a questo sviluppo. I produttori di
78 hardware vogliono assicurarsi che il loro prodotti siano supportati da Linux,
79 rendendo questi prodotti attrattivi agli utenti Linux. I produttori di
80 sistemi integrati, che usano Linux come componente di un prodotto integrato,
81 vogliono che Linux sia capace ed adeguato agli obiettivi ed il più possibile
82 alla mano. Fornitori ed altri produttori di software che basano i propri
83 prodotti su Linux hanno un chiaro interesse verso capacità, prestazioni ed
84 affidabilità del kernel Linux. E gli utenti finali, anche, spesso vorrebbero
85 cambiare Linux per renderlo più aderente alle proprie necessità.
87 Una delle caratteristiche più coinvolgenti di Linux è quella dell'accessibilità
88 per gli sviluppatori; chiunque con le capacità richieste può migliorare
89 Linux ed influenzarne la direzione di sviluppo. Prodotti non open-source non
90 possono offrire questo tipo di apertura, che è una caratteristica del software
91 libero. Ma, anzi, il kernel è persino più aperto rispetto a molti altri
92 progetti di software libero. Un classico ciclo di sviluppo trimestrale può
93 coinvolgere 1000 sviluppatori che lavorano per più di 100 differenti aziende
94 (o per nessuna azienda).
96 Lavorare con la comunità di sviluppo del kernel non è particolarmente
97 difficile. Ma, ciononostante, diversi potenziali contributori hanno trovato
98 delle difficoltà quando hanno cercato di lavorare sul kernel. La comunità del
99 kernel utilizza un proprio modo di operare che gli permette di funzionare
100 agevolmente (e genera un prodotto di alta qualità) in un ambiente dove migliaia
101 di stringhe di codice sono modificate ogni giorni. Quindi non deve sorprendere
102 che il processo di sviluppo del kernel differisca notevolmente dai metodi di
103 sviluppo privati.
105 Il processo di sviluppo del Kernel può, dall'altro lato, risultare
106 intimidatorio e strano ai nuovi sviluppatori, ma ha dietro di se buone ragioni
107 e solide esperienze. Uno sviluppatore che non comprende i modi della comunità
108 del kernel (o, peggio, che cerchi di aggirarli o violarli) avrà un'esperienza
109 deludente nel proprio bagaglio. La comunità di sviluppo, sebbene sia utile
110 a coloro che cercano di imparare, ha poco tempo da dedicare a coloro che non
111 ascoltano o coloro che non sono interessati al processo di sviluppo.
113 Si spera che coloro che leggono questo documento saranno in grado di evitare
114 queste esperienze spiacevoli. C'è molto materiale qui, ma lo sforzo della
115 lettura sarà ripagato in breve tempo. La comunità di sviluppo ha sempre
116 bisogno di sviluppatori che vogliano aiutare a rendere il kernel migliore;
117 il testo seguente potrebbe esservi d'aiuto - o essere d'aiuto ai vostri
118 collaboratori- per entrare a far parte della nostra comunità.
120 Crediti
121 -------
123 Questo documento è stato scritto da Jonathan Corbet, corbet@lwn.net.
124 È stato migliorato da Johannes Berg, James Berry, Alex Chiang, Roland
125 Dreier, Randy Dunlap, Jake Edge, Jiri Kosina, Matt Mackall, Arthur Marsh,
126 Amanda McPherson, Andrew Morton, Andrew Price, Tsugikazu Shibata e Jochen Voß.
128 Questo lavoro è stato supportato dalla Linux Foundation; un ringraziamento
129 speciale ad Amanda McPherson, che ha visto il valore di questo lavoro e lo ha
130 reso possibile.
132 L'importanza d'avere il codice nei sorgenti principali
133 ------------------------------------------------------
135 Alcune aziende e sviluppatori ogni tanto si domandano perché dovrebbero
136 preoccuparsi di apprendere come lavorare con la comunità del kernel e di
137 inserire il loro codice nel ramo di sviluppo principale (per ramo principale
138 s'intende quello mantenuto da Linus Torvalds e usato come base dai
139 distributori Linux). Nel breve termine, contribuire al codice può sembrare
140 un costo inutile; può sembra più facile tenere separato il proprio codice e
141 supportare direttamente i suoi utilizzatori. La verità è che il tenere il
142 codice separato ("fuori dai sorgenti", *"out-of-tree"*) è un falso risparmio.
144 Per dimostrare i costi di un codice "fuori dai sorgenti", eccovi
145 alcuni aspetti rilevanti del processo di sviluppo kernel; la maggior parte
146 di essi saranno approfonditi dettagliatamente più avanti in questo documento.
147 Considerate:
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.
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.
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.
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.
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à.
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à.
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".
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.
209 Il ragionamento sopra citato si applica ad ogni codice "fuori dai sorgenti"
210 dal kernel, incluso il codice proprietario distribuito solamente in formato
211 binario. Ci sono, comunque, dei fattori aggiuntivi che dovrebbero essere
212 tenuti in conto prima di prendere in considerazione qualsiasi tipo di
213 distribuzione binaria di codice kernel. Questo include che:
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.
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à.
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.
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.
243 I produttori di sistemi integrati, in particolare, potrebbero esser tentati
244 dall'evitare molto di ciò che è stato detto in questa sezione, credendo che
245 stiano distribuendo un prodotto finito che utilizza una versione del kernel
246 immutabile e che non richiede un ulteriore sviluppo dopo il rilascio. Questa
247 idea non comprende il valore di una vasta revisione del codice e il valore
248 del permettere ai propri utenti di aggiungere funzionalità al vostro prodotto.
249 Ma anche questi prodotti, hanno una vita commerciale limitata, dopo la quale
250 deve essere rilasciata una nuova versione. A quel punto, i produttori il cui
251 codice è nel ramo principale di sviluppo avranno un codice ben mantenuto e
252 saranno in una posizione migliore per ottenere velocemente un nuovo prodotto
253 pronto per essere distribuito.
256 Licenza
257 -------
259 IL codice Linux utilizza diverse licenze, ma il codice completo deve essere
260 compatibile con la seconda versione della licenza GNU General Public License
261 (GPLv2), che è la licenza che copre la distribuzione del kernel.
262 Nella pratica, ciò significa che tutti i contributi al codice sono coperti
263 anche'essi dalla GPLv2 (con, opzionalmente, una dicitura che permette la
264 possibilità di distribuirlo con licenze più recenti di GPL) o dalla licenza
265 three-clause BSD. Qualsiasi contributo che non è coperto da una licenza
266 compatibile non verrà accettata nel kernel.
268 Per il codice sottomesso al kernel non è necessario (o richiesto) la
269 concessione del Copyright. Tutto il codice inserito nel ramo principale del
270 kernel conserva la sua proprietà originale; ne risulta che ora il kernel abbia
271 migliaia di proprietari.
273 Una conseguenza di questa organizzazione della proprietà è che qualsiasi
274 tentativo di modifica della licenza del kernel è destinata ad un quasi sicuro
275 fallimento. Esistono alcuni scenari pratici nei quali il consenso di tutti
276 i detentori di copyright può essere ottenuto (o il loro codice verrà rimosso
277 dal kernel). Quindi, in sostanza, non esiste la possibilità che si giunga ad
278 una versione 3 della licenza GPL nel prossimo futuro.
280 È imperativo che tutto il codice che contribuisce al kernel sia legittimamente
281 software libero. Per questa ragione, un codice proveniente da un contributore
282 anonimo (o sotto pseudonimo) non verrà accettato. È richiesto a tutti i
283 contributori di firmare il proprio codice, attestando così che quest'ultimo
284 può essere distribuito insieme al kernel sotto la licenza GPL. Il codice che
285 non è stato licenziato come software libero dal proprio creatore, o che
286 potrebbe creare problemi di copyright per il kernel (come il codice derivante
287 da processi di ingegneria inversa senza le opportune tutele), non può essere
288 diffuso.
290 Domande relative a questioni legate al copyright sono frequenti nelle liste
291 di discussione dedicate allo sviluppo di Linux. Tali quesiti, normalmente,
292 non riceveranno alcuna risposta, ma una cosa deve essere tenuta presente:
293 le persone che risponderanno a quelle domande non sono avvocati e non possono
294 fornire supporti legali. Se avete questioni legali relative ai sorgenti
295 del codice Linux, non esiste alternativa che quella di parlare con un
296 avvocato esperto nel settore. Fare affidamento sulle risposte ottenute da
297 una lista di discussione tecnica è rischioso.