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.
298