summaryrefslogtreecommitdiffstats
path: root/Documentation/translations/it_IT/process/1.Intro.rst
diff options
context:
space:
mode:
authorDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-27 10:05:51 +0000
committerDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-27 10:05:51 +0000
commit5d1646d90e1f2cceb9f0828f4b28318cd0ec7744 (patch)
treea94efe259b9009378be6d90eb30d2b019d95c194 /Documentation/translations/it_IT/process/1.Intro.rst
parentInitial commit. (diff)
downloadlinux-upstream/5.10.209.tar.xz
linux-upstream/5.10.209.zip
Adding upstream version 5.10.209.upstream/5.10.209upstream
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'Documentation/translations/it_IT/process/1.Intro.rst')
-rw-r--r--Documentation/translations/it_IT/process/1.Intro.rst297
1 files changed, 297 insertions, 0 deletions
diff --git a/Documentation/translations/it_IT/process/1.Intro.rst b/Documentation/translations/it_IT/process/1.Intro.rst
new file mode 100644
index 000000000..c1be6dc39
--- /dev/null
+++ b/Documentation/translations/it_IT/process/1.Intro.rst
@@ -0,0 +1,297 @@
+.. include:: ../disclaimer-ita.rst
+
+:Original: :ref:`Documentation/process/1.Intro.rst <development_process_intro>`
+:Translator: Alessia Mantegazza <amantegazza@vaga.pv.it>
+
+.. _it_development_intro:
+
+Introduzione
+============
+
+Riepilogo generale
+------------------
+
+Il resto di questa sezione riguarda il processo di sviluppo del kernel e
+quella sorta di frustrazione che gli sviluppatori e i loro datori di lavoro
+potrebbero dover affrontare. Ci sono molte ragioni per le quali del codice
+per il kernel debba essere incorporato nel kernel ufficiale, fra le quali:
+disponibilità immediata agli utilizzatori, supporto della comunità in
+differenti modalità, e la capacità di influenzare la direzione dello sviluppo
+del kernel.
+Il codice che contribuisce al kernel Linux deve essere reso disponibile sotto
+una licenza GPL-compatibile.
+
+La sezione :ref:`it_development_process` introduce il processo di sviluppo,
+il ciclo di rilascio del kernel, ed i meccanismi della finestra
+d'incorporazione. Il capitolo copre le varie fasi di una modifica: sviluppo,
+revisione e ciclo d'incorporazione. Ci sono alcuni dibattiti su strumenti e
+liste di discussione. Gli sviluppatori che sono in attesa di poter sviluppare
+qualcosa per il kernel sono invitati ad individuare e sistemare bachi come
+esercizio iniziale.
+
+La sezione :ref:`it_development_early_stage` copre i primi stadi della
+pianificazione di un progetto di sviluppo, con particolare enfasi sul
+coinvolgimento della comunità, il prima possibile.
+
+La sezione :ref:`it_development_coding` riguarda il processo di scrittura
+del codice. Qui, sono esposte le diverse insidie che sono state già affrontate
+da altri sviluppatori. Il capitolo copre anche alcuni dei requisiti per le
+modifiche, ed esiste un'introduzione ad alcuni strumenti che possono aiutarvi
+nell'assicurarvi che le modifiche per il kernel siano corrette.
+
+La sezione :ref:`it_development_posting` parla del processo di pubblicazione
+delle modifiche per la revisione. Per essere prese in considerazione dalla
+comunità di sviluppo, le modifiche devono essere propriamente formattate ed
+esposte, e devono essere inviate nel posto giusto. Seguire i consigli presenti
+in questa sezione dovrebbe essere d'aiuto nell'assicurare la migliore
+accoglienza possibile del vostro lavoro.
+
+La sezione :ref:`it_development_followthrough` copre ciò che accade dopo
+la pubblicazione delle modifiche; a questo punto il lavoro è lontano
+dall'essere concluso. Lavorare con i revisori è una parte cruciale del
+processo di sviluppo; questa sezione offre una serie di consigli su come
+evitare problemi in questa importante fase. Gli sviluppatori sono diffidenti
+nell'affermare che il lavoro è concluso quando una modifica è incorporata nei
+sorgenti principali.
+
+La sezione :ref:`it_development_advancedtopics` introduce un paio di argomenti
+"avanzati": gestire le modifiche con git e controllare le modifiche pubblicate
+da altri.
+
+La sezione :ref:`it_development_conclusion` chiude il documento con dei
+riferimenti ad altre fonti che forniscono ulteriori informazioni sullo sviluppo
+del kernel.
+
+Di cosa parla questo documento
+------------------------------
+
+Il kernel Linux, ha oltre 8 milioni di linee di codice e ben oltre 1000
+contributori ad ogni rilascio; è uno dei più vasti e più attivi software
+liberi progettati mai esistiti. Sin dal sul modesto inizio nel 1991,
+questo kernel si è evoluto nel miglior componente per sistemi operativi
+che fanno funzionare piccoli riproduttori musicali, PC, grandi super computer
+e tutte le altre tipologie di sistemi fra questi estremi. È una soluzione
+robusta, efficiente ed adattabile a praticamente qualsiasi situazione.
+
+Con la crescita di Linux è arrivato anche un aumento di sviluppatori
+(ed aziende) desiderosi di partecipare a questo sviluppo. I produttori di
+hardware vogliono assicurarsi che il loro prodotti siano supportati da Linux,
+rendendo questi prodotti attrattivi agli utenti Linux. I produttori di
+sistemi integrati, che usano Linux come componente di un prodotto integrato,
+vogliono che Linux sia capace ed adeguato agli obiettivi ed il più possibile
+alla mano. Fornitori ed altri produttori di software che basano i propri
+prodotti su Linux hanno un chiaro interesse verso capacità, prestazioni ed
+affidabilità del kernel Linux. E gli utenti finali, anche, spesso vorrebbero
+cambiare Linux per renderlo più aderente alle proprie necessità.
+
+Una delle caratteristiche più coinvolgenti di Linux è quella dell'accessibilità
+per gli sviluppatori; chiunque con le capacità richieste può migliorare
+Linux ed influenzarne la direzione di sviluppo. Prodotti non open-source non
+possono offrire questo tipo di apertura, che è una caratteristica del software
+libero. Ma, anzi, il kernel è persino più aperto rispetto a molti altri
+progetti di software libero. Un classico ciclo di sviluppo trimestrale può
+coinvolgere 1000 sviluppatori che lavorano per più di 100 differenti aziende
+(o per nessuna azienda).
+
+Lavorare con la comunità di sviluppo del kernel non è particolarmente
+difficile. Ma, ciononostante, diversi potenziali contributori hanno trovato
+delle difficoltà quando hanno cercato di lavorare sul kernel. La comunità del
+kernel utilizza un proprio modo di operare che gli permette di funzionare
+agevolmente (e genera un prodotto di alta qualità) in un ambiente dove migliaia
+di stringhe di codice sono modificate ogni giorni. Quindi non deve sorprendere
+che il processo di sviluppo del kernel differisca notevolmente dai metodi di
+sviluppo privati.
+
+Il processo di sviluppo del Kernel può, dall'altro lato, risultare
+intimidatorio e strano ai nuovi sviluppatori, ma ha dietro di se buone ragioni
+e solide esperienze. Uno sviluppatore che non comprende i modi della comunità
+del kernel (o, peggio, che cerchi di aggirarli o violarli) avrà un'esperienza
+deludente nel proprio bagaglio. La comunità di sviluppo, sebbene sia utile
+a coloro che cercano di imparare, ha poco tempo da dedicare a coloro che non
+ascoltano o coloro che non sono interessati al processo di sviluppo.
+
+Si spera che coloro che leggono questo documento saranno in grado di evitare
+queste esperienze spiacevoli. C'è molto materiale qui, ma lo sforzo della
+lettura sarà ripagato in breve tempo. La comunità di sviluppo ha sempre
+bisogno di sviluppatori che vogliano aiutare a rendere il kernel migliore;
+il testo seguente potrebbe esservi d'aiuto - o essere d'aiuto ai vostri
+collaboratori- per entrare a far parte della nostra comunità.
+
+Crediti
+-------
+
+Questo documento è stato scritto da Jonathan Corbet, corbet@lwn.net.
+È stato migliorato da Johannes Berg, James Berry, Alex Chiang, Roland
+Dreier, Randy Dunlap, Jake Edge, Jiri Kosina, Matt Mackall, Arthur Marsh,
+Amanda McPherson, Andrew Morton, Andrew Price, Tsugikazu Shibata e Jochen Voß.
+
+Questo lavoro è stato supportato dalla Linux Foundation; un ringraziamento
+speciale ad Amanda McPherson, che ha visto il valore di questo lavoro e lo ha
+reso possibile.
+
+L'importanza d'avere il codice nei sorgenti principali
+------------------------------------------------------
+
+Alcune aziende e sviluppatori ogni tanto si domandano perché dovrebbero
+preoccuparsi di apprendere come lavorare con la comunità del kernel e di
+inserire il loro codice nel ramo di sviluppo principale (per ramo principale
+s'intende quello mantenuto da Linus Torvalds e usato come base dai
+distributori Linux). Nel breve termine, contribuire al codice può sembrare
+un costo inutile; può sembra più facile tenere separato il proprio codice e
+supportare direttamente i suoi utilizzatori. La verità è che il tenere il
+codice separato ("fuori dai sorgenti", *"out-of-tree"*) è un falso risparmio.
+
+Per dimostrare i costi di un codice "fuori dai sorgenti", eccovi
+alcuni aspetti rilevanti del processo di sviluppo kernel; la maggior parte
+di essi saranno approfonditi dettagliatamente più avanti in questo documento.
+Considerate:
+
+- Il codice che è stato inserito nel ramo principale del kernel è disponibile
+ a tutti gli utilizzatori Linux. Sarà automaticamente presente in tutte le
+ distribuzioni che lo consentono. Non c'è bisogno di: driver per dischi,
+ scaricare file, o della scocciatura del dover supportare diverse versioni di
+ diverse distribuzioni; funziona già tutto, per gli sviluppatori e per gli
+ utilizzatori. L'inserimento nel ramo principale risolve un gran numero di
+ problemi di distribuzione e di supporto.
+
+- Nonostante gli sviluppatori kernel si sforzino di tenere stabile
+ l'interfaccia dello spazio utente, quella interna al kernel è in continuo
+ cambiamento. La mancanza di un'interfaccia interna è deliberatamente una
+ decisione di progettazione; ciò permette che i miglioramenti fondamentali
+ vengano fatti in un qualsiasi momento e che risultino fatti con un codice di
+ alta qualità. Ma una delle conseguenze di questa politica è che qualsiasi
+ codice "fuori dai sorgenti" richiede costante manutenzione per renderlo
+ funzionante coi kernel più recenti. Tenere un codice "fuori dai sorgenti"
+ richiede una mole di lavoro significativa solo per farlo funzionare.
+
+ Invece, il codice che si trova nel ramo principale non necessita di questo
+ tipo di lavoro poiché ad ogni sviluppatore che faccia una modifica alle
+ interfacce viene richiesto di sistemare anche il codice che utilizza
+ quell'interfaccia. Quindi, il codice che è stato inserito nel ramo principale
+ ha dei costi di mantenimento significativamente più bassi.
+
+- Oltre a ciò, spesso il codice che è all'interno del kernel sarà migliorato da
+ altri sviluppatori. Dare pieni poteri alla vostra comunità di utenti e ai
+ clienti può portare a sorprendenti risultati che migliorano i vostri
+ prodotti.
+
+- Il codice kernel è soggetto a revisioni, sia prima che dopo l'inserimento
+ nel ramo principale. Non importa quanto forti fossero le abilità dello
+ sviluppatore originale, il processo di revisione troverà il modo di migliore
+ il codice. Spesso la revisione trova bachi importanti e problemi di
+ sicurezza. Questo è particolarmente vero per il codice che è stato
+ sviluppato in un ambiente chiuso; tale codice ottiene un forte beneficio
+ dalle revisioni provenienti da sviluppatori esteri. Il codice
+ "fuori dai sorgenti", invece, è un codice di bassa qualità.
+
+- La partecipazione al processo di sviluppo costituisce la vostra via per
+ influenzare la direzione di sviluppo del kernel. Gli utilizzatori che
+ "reclamano da bordo campo" sono ascoltati, ma gli sviluppatori attivi
+ hanno una voce più forte - e la capacità di implementare modifiche che
+ renderanno il kernel più funzionale alle loro necessità.
+
+- Quando il codice è gestito separatamente, esiste sempre la possibilità che
+ terze parti contribuiscano con una differente implementazione che fornisce
+ le stesse funzionalità. Se dovesse accadere, l'inserimento del codice
+ diventerà molto più difficile - fino all'impossibilità. Poi, dovrete far
+ fronte a delle alternative poco piacevoli, come: (1) mantenere un elemento
+ non standard "fuori dai sorgenti" per un tempo indefinito, o (2) abbandonare
+ il codice e far migrare i vostri utenti alla versione "nei sorgenti".
+
+- Contribuire al codice è l'azione fondamentale che fa funzionare tutto il
+ processo. Contribuendo attraverso il vostro codice potete aggiungere nuove
+ funzioni al kernel e fornire competenze ed esempi che saranno utili ad
+ altri sviluppatori. Se avete sviluppato del codice Linux (o state pensando
+ di farlo), avete chiaramente interesse nel far proseguire il successo di
+ questa piattaforma. Contribuire al codice è une delle migliori vie per
+ aiutarne il successo.
+
+Il ragionamento sopra citato si applica ad ogni codice "fuori dai sorgenti"
+dal kernel, incluso il codice proprietario distribuito solamente in formato
+binario. Ci sono, comunque, dei fattori aggiuntivi che dovrebbero essere
+tenuti in conto prima di prendere in considerazione qualsiasi tipo di
+distribuzione binaria di codice kernel. Questo include che:
+
+- Le questioni legali legate alla distribuzione di moduli kernel proprietari
+ sono molto nebbiose; parecchi detentori di copyright sul kernel credono che
+ molti moduli binari siano prodotti derivati del kernel e che, come risultato,
+ la loro diffusione sia una violazione della licenza generale di GNU (della
+ quale si parlerà più avanti). L'autore qui non è un avvocato, e
+ niente in questo documento può essere considerato come un consiglio legale.
+ Il vero stato legale dei moduli proprietari può essere determinato
+ esclusivamente da un giudice. Ma l'incertezza che perseguita quei moduli
+ è lì comunque.
+
+- I moduli binari aumentano di molto la difficoltà di fare debugging del
+ kernel, al punto che la maggior parte degli sviluppatori del kernel non
+ vorranno nemmeno tentare. Quindi la diffusione di moduli esclusivamente
+ binari renderà difficile ai vostri utilizzatori trovare un supporto dalla
+ comunità.
+
+- Il supporto è anche difficile per i distributori di moduli binari che devono
+ fornire una versione del modulo per ogni distribuzione e per ogni versione
+ del kernel che vogliono supportate. Per fornire una copertura ragionevole e
+ comprensiva, può essere richiesto di produrre dozzine di singoli moduli.
+ E inoltre i vostri utilizzatori dovranno aggiornare il vostro modulo
+ separatamente ogni volta che aggiornano il loro kernel.
+
+- Tutto ciò che è stato detto prima riguardo alla revisione del codice si
+ applica doppiamente al codice proprietario. Dato che questo codice non è
+ del tutto disponibile, non può essere revisionato dalla comunità e avrà,
+ senza dubbio, seri problemi.
+
+I produttori di sistemi integrati, in particolare, potrebbero esser tentati
+dall'evitare molto di ciò che è stato detto in questa sezione, credendo che
+stiano distribuendo un prodotto finito che utilizza una versione del kernel
+immutabile e che non richiede un ulteriore sviluppo dopo il rilascio. Questa
+idea non comprende il valore di una vasta revisione del codice e il valore
+del permettere ai propri utenti di aggiungere funzionalità al vostro prodotto.
+Ma anche questi prodotti, hanno una vita commerciale limitata, dopo la quale
+deve essere rilasciata una nuova versione. A quel punto, i produttori il cui
+codice è nel ramo principale di sviluppo avranno un codice ben mantenuto e
+saranno in una posizione migliore per ottenere velocemente un nuovo prodotto
+pronto per essere distribuito.
+
+
+Licenza
+-------
+
+IL codice Linux utilizza diverse licenze, ma il codice completo deve essere
+compatibile con la seconda versione della licenza GNU General Public License
+(GPLv2), che è la licenza che copre la distribuzione del kernel.
+Nella pratica, ciò significa che tutti i contributi al codice sono coperti
+anche'essi dalla GPLv2 (con, opzionalmente, una dicitura che permette la
+possibilità di distribuirlo con licenze più recenti di GPL) o dalla licenza
+three-clause BSD. Qualsiasi contributo che non è coperto da una licenza
+compatibile non verrà accettata nel kernel.
+
+Per il codice sottomesso al kernel non è necessario (o richiesto) la
+concessione del Copyright. Tutto il codice inserito nel ramo principale del
+kernel conserva la sua proprietà originale; ne risulta che ora il kernel abbia
+migliaia di proprietari.
+
+Una conseguenza di questa organizzazione della proprietà è che qualsiasi
+tentativo di modifica della licenza del kernel è destinata ad un quasi sicuro
+fallimento. Esistono alcuni scenari pratici nei quali il consenso di tutti
+i detentori di copyright può essere ottenuto (o il loro codice verrà rimosso
+dal kernel). Quindi, in sostanza, non esiste la possibilità che si giunga ad
+una versione 3 della licenza GPL nel prossimo futuro.
+
+È imperativo che tutto il codice che contribuisce al kernel sia legittimamente
+software libero. Per questa ragione, un codice proveniente da un contributore
+anonimo (o sotto pseudonimo) non verrà accettato. È richiesto a tutti i
+contributori di firmare il proprio codice, attestando così che quest'ultimo
+può essere distribuito insieme al kernel sotto la licenza GPL. Il codice che
+non è stato licenziato come software libero dal proprio creatore, o che
+potrebbe creare problemi di copyright per il kernel (come il codice derivante
+da processi di ingegneria inversa senza le opportune tutele), non può essere
+diffuso.
+
+Domande relative a questioni legate al copyright sono frequenti nelle liste
+di discussione dedicate allo sviluppo di Linux. Tali quesiti, normalmente,
+non riceveranno alcuna risposta, ma una cosa deve essere tenuta presente:
+le persone che risponderanno a quelle domande non sono avvocati e non possono
+fornire supporti legali. Se avete questioni legali relative ai sorgenti
+del codice Linux, non esiste alternativa che quella di parlare con un
+avvocato esperto nel settore. Fare affidamento sulle risposte ottenute da
+una lista di discussione tecnica è rischioso.