1 .. include:: ../disclaimer-ita.rst
2
3 :Original: :ref:`Documentation/process/1.Intro
4 :Translator: Alessia Mantegazza <amantegazza@va
5
6 .. _it_development_intro:
7
8 Introduzione
9 ============
10
11 Riepilogo generale
12 ------------------
13
14 Il resto di questa sezione riguarda il process
15 quella sorta di frustrazione che gli sviluppat
16 potrebbero dover affrontare. Ci sono molte ra
17 per il kernel debba essere incorporato nel ker
18 disponibilità immediata agli utilizzatori, su
19 differenti modalità , e la capacità di influe
20 del kernel.
21 Il codice che contribuisce al kernel Linux dev
22 una licenza GPL-compatibile.
23
24 La sezione :ref:`it_development_process` intro
25 il ciclo di rilascio del kernel, ed i meccanis
26 d'incorporazione. Il capitolo copre le varie
27 revisione e ciclo d'incorporazione. Ci sono al
28 liste di discussione. Gli sviluppatori che son
29 qualcosa per il kernel sono invitati ad indivi
30 esercizio iniziale.
31
32 La sezione :ref:`it_development_early_stage` c
33 pianificazione di un progetto di sviluppo, con
34 coinvolgimento della comunità , il prima possi
35
36 La sezione :ref:`it_development_coding` riguar
37 del codice. Qui, sono esposte le diverse insid
38 da altri sviluppatori. Il capitolo copre anch
39 modifiche, ed esiste un'introduzione ad alcuni
40 nell'assicurarvi che le modifiche per il kerne
41
42 La sezione :ref:`it_development_posting` parla
43 delle modifiche per la revisione. Per essere p
44 comunità di sviluppo, le modifiche devono ess
45 esposte, e devono essere inviate nel posto giu
46 in questa sezione dovrebbe essere d'aiuto nell
47 accoglienza possibile del vostro lavoro.
48
49 La sezione :ref:`it_development_followthrough`
50 la pubblicazione delle modifiche; a questo pun
51 dall'essere concluso. Lavorare con i revisori
52 processo di sviluppo; questa sezione offre una
53 evitare problemi in questa importante fase. G
54 nell'affermare che il lavoro è concluso quand
55 sorgenti principali.
56
57 La sezione :ref:`it_development_advancedtopics
58 "avanzati": gestire le modifiche con git e con
59 da altri.
60
61 La sezione :ref:`it_development_conclusion` ch
62 riferimenti ad altre fonti che forniscono ulte
63 del kernel.
64
65 Di cosa parla questo documento
66 ------------------------------
67
68 Il kernel Linux, ha oltre 8 milioni di linee d
69 contributori ad ogni rilascio; è uno dei più
70 liberi progettati mai esistiti. Sin dal sul m
71 questo kernel si è evoluto nel miglior compon
72 che fanno funzionare piccoli riproduttori musi
73 e tutte le altre tipologie di sistemi fra ques
74 robusta, efficiente ed adattabile a praticamen
75
76 Con la crescita di Linux è arrivato anche un
77 (ed aziende) desiderosi di partecipare a quest
78 hardware vogliono assicurarsi che il loro prod
79 rendendo questi prodotti attrattivi agli utent
80 sistemi integrati, che usano Linux come compon
81 vogliono che Linux sia capace ed adeguato agli
82 alla mano. Fornitori ed altri produttori di so
83 prodotti su Linux hanno un chiaro interesse ve
84 affidabilità del kernel Linux. E gli utenti
85 cambiare Linux per renderlo più aderente alle
86
87 Una delle caratteristiche più coinvolgenti di
88 per gli sviluppatori; chiunque con le capacitÃ
89 Linux ed influenzarne la direzione di sviluppo
90 possono offrire questo tipo di apertura, che Ã
91 libero. Ma, anzi, il kernel è persino più a
92 progetti di software libero. Un classico cicl
93 coinvolgere 1000 sviluppatori che lavorano per
94 (o per nessuna azienda).
95
96 Lavorare con la comunità di sviluppo del kern
97 difficile. Ma, ciononostante, diversi potenzi
98 delle difficoltà quando hanno cercato di lavo
99 kernel utilizza un proprio modo di operare che
100 agevolmente (e genera un prodotto di alta qual
101 di stringhe di codice sono modificate ogni gio
102 che il processo di sviluppo del kernel differi
103 sviluppo privati.
104
105 Il processo di sviluppo del Kernel può, dall'
106 intimidatorio e strano ai nuovi sviluppatori,
107 e solide esperienze. Uno sviluppatore che non
108 del kernel (o, peggio, che cerchi di aggirarli
109 deludente nel proprio bagaglio. La comunitÃ
110 a coloro che cercano di imparare, ha poco temp
111 ascoltano o coloro che non sono interessati al
112
113 Si spera che coloro che leggono questo documen
114 queste esperienze spiacevoli. C'è molto mat
115 lettura sarà ripagato in breve tempo. La com
116 bisogno di sviluppatori che vogliano aiutare a
117 il testo seguente potrebbe esservi d'aiuto - o
118 collaboratori- per entrare a far parte della n
119
120 Crediti
121 -------
122
123 Questo documento è stato scritto da Jonathan
124 È stato migliorato da Johannes Berg, James Be
125 Dreier, Randy Dunlap, Jake Edge, Jiri Kosina,
126 Amanda McPherson, Andrew Morton, Andrew Price,
127
128 Questo lavoro è stato supportato dalla Linux
129 speciale ad Amanda McPherson, che ha visto il
130 reso possibile.
131
132 L'importanza d'avere il codice nei sorgenti pr
133 ----------------------------------------------
134
135 Alcune aziende e sviluppatori ogni tanto si do
136 preoccuparsi di apprendere come lavorare con l
137 inserire il loro codice nel ramo di sviluppo p
138 s'intende quello mantenuto da Linus Torvalds e
139 distributori Linux). Nel breve termine, contri
140 un costo inutile; può sembra più facile tene
141 supportare direttamente i suoi utilizzatori. L
142 codice separato ("fuori dai sorgenti", *"out-o
143
144 Per dimostrare i costi di un codice "fuori dai
145 alcuni aspetti rilevanti del processo di svilu
146 di essi saranno approfonditi dettagliatamente
147 Considerate:
148
149 - Il codice che è stato inserito nel ramo pri
150 a tutti gli utilizzatori Linux. Sarà automa
151 distribuzioni che lo consentono. Non c'è bi
152 scaricare file, o della scocciatura del dove
153 diverse distribuzioni; funziona già tutto,
154 utilizzatori. L'inserimento nel ramo princip
155 problemi di distribuzione e di supporto.
156
157 - Nonostante gli sviluppatori kernel si sforzi
158 l'interfaccia dello spazio utente, quella in
159 cambiamento. La mancanza di un'interfaccia i
160 decisione di progettazione; ciò permette ch
161 vengano fatti in un qualsiasi momento e che
162 alta qualità . Ma una delle conseguenze di q
163 codice "fuori dai sorgenti" richiede costant
164 funzionante coi kernel più recenti. Tenere
165 richiede una mole di lavoro significativa so
166
167 Invece, il codice che si trova nel ramo prin
168 tipo di lavoro poiché ad ogni sviluppatore
169 interfacce viene richiesto di sistemare anch
170 quell'interfaccia. Quindi, il codice che è
171 ha dei costi di mantenimento significativame
172
173 - Oltre a ciò, spesso il codice che è all'in
174 altri sviluppatori. Dare pieni poteri alla v
175 clienti può portare a sorprendenti risultat
176 prodotti.
177
178 - Il codice kernel è soggetto a revisioni, si
179 nel ramo principale. Non importa quanto for
180 sviluppatore originale, il processo di revis
181 il codice. Spesso la revisione trova bachi
182 sicurezza. Questo è particolarmente vero p
183 sviluppato in un ambiente chiuso; tale codic
184 dalle revisioni provenienti da sviluppatori
185 "fuori dai sorgenti", invece, è un codice d
186
187 - La partecipazione al processo di sviluppo co
188 influenzare la direzione di sviluppo del ker
189 "reclamano da bordo campo" sono ascoltati, m
190 hanno una voce più forte - e la capacità d
191 renderanno il kernel più funzionale alle lo
192
193 - Quando il codice è gestito separatamente, e
194 terze parti contribuiscano con una different
195 le stesse funzionalità . Se dovesse accader
196 diventerà molto più difficile - fino all'i
197 fronte a delle alternative poco piacevoli, c
198 non standard "fuori dai sorgenti" per un tem
199 il codice e far migrare i vostri utenti alla
200
201 - Contribuire al codice è l'azione fondamenta
202 processo. Contribuendo attraverso il vostro
203 funzioni al kernel e fornire competenze ed e
204 altri sviluppatori. Se avete sviluppato del
205 di farlo), avete chiaramente interesse nel f
206 questa piattaforma. Contribuire al codice è
207 aiutarne il successo.
208
209 Il ragionamento sopra citato si applica ad ogn
210 dal kernel, incluso il codice proprietario dis
211 binario. Ci sono, comunque, dei fattori aggiu
212 tenuti in conto prima di prendere in considera
213 distribuzione binaria di codice kernel. Questo
214
215 - Le questioni legali legate alla distribuzion
216 sono molto nebbiose; parecchi detentori di c
217 molti moduli binari siano prodotti derivati
218 la loro diffusione sia una violazione della
219 quale si parlerà più avanti). L'autore qu
220 niente in questo documento può essere consi
221 Il vero stato legale dei moduli proprietari
222 esclusivamente da un giudice. Ma l'incertezz
223 è lì comunque.
224
225 - I moduli binari aumentano di molto la diffic
226 kernel, al punto che la maggior parte degli
227 vorranno nemmeno tentare. Quindi la diffusi
228 binari renderà difficile ai vostri utilizza
229 comunità .
230
231 - Il supporto è anche difficile per i distrib
232 fornire una versione del modulo per ogni dis
233 del kernel che vogliono supportate. Per for
234 comprensiva, può essere richiesto di produr
235 E inoltre i vostri utilizzatori dovranno agg
236 separatamente ogni volta che aggiornano il l
237
238 - Tutto ciò che è stato detto prima riguardo
239 applica doppiamente al codice proprietario.
240 del tutto disponibile, non può essere revis
241 senza dubbio, seri problemi.
242
243 I produttori di sistemi integrati, in particol
244 dall'evitare molto di ciò che è stato detto
245 stiano distribuendo un prodotto finito che uti
246 immutabile e che non richiede un ulteriore svi
247 idea non comprende il valore di una vasta revi
248 del permettere ai propri utenti di aggiungere
249 Ma anche questi prodotti, hanno una vita comme
250 deve essere rilasciata una nuova versione. A
251 codice è nel ramo principale di sviluppo avra
252 saranno in una posizione migliore per ottenere
253 pronto per essere distribuito.
254
255
256 Licenza
257 -------
258
259 IL codice Linux utilizza diverse licenze, ma i
260 compatibile con la seconda versione della lice
261 (GPLv2), che è la licenza che copre la distri
262 Nella pratica, ciò significa che tutti i cont
263 anche'essi dalla GPLv2 (con, opzionalmente, un
264 possibilità di distribuirlo con licenze più
265 three-clause BSD. Qualsiasi contributo che no
266 compatibile non verrà accettata nel kernel.
267
268 Per il codice sottomesso al kernel non è nece
269 concessione del Copyright. Tutto il codice in
270 kernel conserva la sua proprietà originale; n
271 migliaia di proprietari.
272
273 Una conseguenza di questa organizzazione della
274 tentativo di modifica della licenza del kernel
275 fallimento. Esistono alcuni scenari pratici n
276 i detentori di copyright può essere ottenuto
277 dal kernel). Quindi, in sostanza, non esiste
278 una versione 3 della licenza GPL nel prossimo
279
280 È imperativo che tutto il codice che contribu
281 software libero. Per questa ragione, un codic
282 anonimo (o sotto pseudonimo) non verrà accett
283 contributori di firmare il proprio codice, att
284 può essere distribuito insieme al kernel sott
285 non è stato licenziato come software libero d
286 potrebbe creare problemi di copyright per il k
287 da processi di ingegneria inversa senza le opp
288 diffuso.
289
290 Domande relative a questioni legate al copyrig
291 di discussione dedicate allo sviluppo di Linux
292 non riceveranno alcuna risposta, ma una cosa d
293 le persone che risponderanno a quelle domande
294 fornire supporti legali. Se avete questioni l
295 del codice Linux, non esiste alternativa che q
296 avvocato esperto nel settore. Fare affidament
297 una lista di discussione tecnica è rischioso.
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.