Documentation/translations/it_IT/process/1.Intro.rst

   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
   8 Introduzione
   9 ============
  10
  11 Riepilogo generale
  12 ------------------
  13
  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.
  23
  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.
  31
  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.
  35
  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.
  41
  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.
  48
  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.
  56
  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.
  60
  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.
  64
  65 Di cosa parla questo documento
  66 ------------------------------
  67
  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.
  75
  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à.
  86
  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).
  95
  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.
 104
 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.
 112
 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à.
 119
 120 Crediti
 121 -------
 122
 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ß.
 127
 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.
 131
 132 L'importanza d'avere il codice nei sorgenti principali
 133 ------------------------------------------------------
 134
 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.
 143
 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:
 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
 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:
 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
 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.
 254
 255
 256 Licenza
 257 -------
 258
 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.
 267
 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.
 272
 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.
 279
 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.
 289
 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.