summaryrefslogtreecommitdiff
path: root/Documentation/translations/it_IT/process/2.Process.rst
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/translations/it_IT/process/2.Process.rst')
-rw-r--r--Documentation/translations/it_IT/process/2.Process.rst531
1 files changed, 531 insertions, 0 deletions
diff --git a/Documentation/translations/it_IT/process/2.Process.rst b/Documentation/translations/it_IT/process/2.Process.rst
new file mode 100644
index 000000000000..9af4d01617c4
--- /dev/null
+++ b/Documentation/translations/it_IT/process/2.Process.rst
@@ -0,0 +1,531 @@
+.. include:: ../disclaimer-ita.rst
+
+:Original: :ref:`Documentation/process/2.Process.rst <development_process>`
+:Translator: Alessia Mantegazza <amantegazza@vaga.pv.it>
+
+.. _it_development_process:
+
+Come funziona il processo di sviluppo
+=====================================
+
+Lo sviluppo del Kernel agli inizi degli anno '90 era abbastanza libero, con
+un numero di utenti e sviluppatori relativamente basso. Con una base
+di milioni di utenti e con 2000 sviluppatori coinvolti nel giro di un anno,
+il kernel da allora ha messo in atto un certo numero di procedure per rendere
+lo sviluppo più agevole. È richiesta una solida conoscenza di come tale
+processo si svolge per poter esserne parte attiva.
+
+Il quadro d'insieme
+-------------------
+
+Gli sviluppatori kernel utilizzano un calendario di rilascio generico, dove
+ogni due o tre mesi viene effettuata un rilascio importante del kernel.
+I rilasci più recenti sono stati:
+
+ ====== =================
+ 4.11 Aprile 30, 2017
+ 4.12 Luglio 2, 2017
+ 4.13 Settembre 3, 2017
+ 4.14 Novembre 12, 2017
+ 4.15 Gennaio 28, 2018
+ 4.16 Aprile 1, 2018
+ ====== =================
+
+Ciascun rilascio 4.x è un importante rilascio del kernel con nuove
+funzionalità, modifiche interne dell'API, e molto altro. Un tipico
+rilascio 4.x contiene quasi 13,000 gruppi di modifiche con ulteriori
+modifiche a parecchie migliaia di linee di codice. La 4.x. è pertanto la
+linea di confine nello sviluppo del kernel Linux; il kernel utilizza un sistema
+di sviluppo continuo che integra costantemente nuove importanti modifiche.
+
+Viene seguita una disciplina abbastanza lineare per l'inclusione delle
+patch di ogni rilascio. All'inizio di ogni ciclo di sviluppo, la
+"finestra di inclusione" viene dichiarata aperta. In quel momento il codice
+ritenuto sufficientemente stabile(e che è accettato dalla comunità di sviluppo)
+viene incluso nel ramo principale del kernel. La maggior parte delle
+patch per un nuovo ciclo di sviluppo (e tutte le più importanti modifiche)
+saranno inserite durante questo periodo, ad un ritmo che si attesta sulle
+1000 modifiche ("patch" o "gruppo di modifiche") al giorno.
+
+(per inciso, vale la pena notare che i cambiamenti integrati durante la
+"finestra di inclusione" non escono dal nulla; questi infatti, sono stati
+raccolti e, verificati in anticipo. Il funzionamento di tale procedimento
+verrà descritto dettagliatamente più avanti).
+
+La finestra di inclusione resta attiva approssimativamente per due settimane.
+Al termine di questo periodo, Linus Torvald dichiarerà che la finestra è
+chiusa e rilascerà il primo degli "rc" del kernel.
+Per il kernel che è destinato ad essere 2.6.40, per esempio, il rilascio
+che emerge al termine della finestra d'inclusione si chiamerà 2.6.40-rc1.
+Questo rilascio indica che il momento di aggiungere nuovi componenti è
+passato, e che è iniziato il periodo di stabilizzazione del prossimo kernel.
+
+Nelle successive sei/dieci settimane, potranno essere sottoposte solo modifiche
+che vanno a risolvere delle problematiche. Occasionalmente potrà essere
+consentita una modifica più consistente, ma tali occasioni sono rare.
+Gli sviluppatori che tenteranno di aggiungere nuovi elementi al di fuori della
+finestra di inclusione, tendenzialmente, riceveranno un accoglienza poco
+amichevole. Come regola generale: se vi perdete la finestra di inclusione per
+un dato componente, la cosa migliore da fare è aspettare il ciclo di sviluppo
+successivo (un'eccezione può essere fatta per i driver per hardware non
+supportati in precedenza; se toccano codice non facente parte di quello
+attuale, che non causino regressioni e che potrebbero essere aggiunti in
+sicurezza in un qualsiasi momento)
+
+Mentre le correzioni si aprono la loro strada all'interno del ramo principale,
+il ritmo delle modifiche rallenta col tempo. Linus rilascia un nuovo
+kernel -rc circa una volta alla settimana; e ne usciranno circa 6 o 9 prima
+che il kernel venga considerato sufficientemente stabile e che il rilascio
+finale 2.6.x venga fatto. A quel punto tutto il processo ricomincerà.
+
+Esempio: ecco com'è andato il ciclo di sviluppo della versione 4.16
+(tutte le date si collocano nel 2018)
+
+
+ ============== =======================================
+ Gennaio 28 4.15 rilascio stabile
+ Febbraio 11 4.16-rc1, finestra di inclusione chiusa
+ Febbraio 18 4.16-rc2
+ Febbraio 25 4.16-rc3
+ Marzo 4 4.16-rc4
+ Marzo 11 4.16-rc5
+ Marzo 18 4.16-rc6
+ Marzo 25 4.16-rc7
+ Aprile 1 4.17 rilascio stabile
+ ============== =======================================
+
+In che modo gli sviluppatori decidono quando chiudere il ciclo di sviluppo e
+creare quindi una rilascio stabile? Un metro valido è il numero di regressioni
+rilevate nel precedente rilascio. Nessun baco è il benvenuto, ma quelli che
+procurano problemi su sistemi che hanno funzionato in passato sono considerati
+particolarmente seri. Per questa ragione, le modifiche che portano ad una
+regressione sono viste sfavorevolmente e verranno quasi sicuramente annullate
+durante il periodo di stabilizzazione.
+
+L'obiettivo degli sviluppatori è quello di aggiustare tutte le regressioni
+conosciute prima che avvenga il rilascio stabile. Nel mondo reale, questo
+tipo di perfezione difficilmente viene raggiunta; esistono troppe variabili
+in un progetto di questa portata. Arriva un punto dove ritardare il rilascio
+finale peggiora la situazione; la quantità di modifiche in attesa della
+prossima finestra di inclusione crescerà enormemente, creando ancor più
+regressioni al giro successivo. Quindi molti kernel 4.x escono con una
+manciata di regressioni delle quali, si spera, nessuna è grave.
+
+Una volta che un rilascio stabile è fatto, il suo costante mantenimento è
+affidato al "squadra stabilità", attualmente composta da Greg Kroah-Hartman.
+Questa squadra rilascia occasionalmente degli aggiornamenti relativi al
+rilascio stabile usando la numerazione 4.x.y. Per essere presa in
+considerazione per un rilascio d'aggiornamento, una modifica deve:
+(1) correggere un baco importante (2) essere già inserita nel ramo principale
+per il prossimo sviluppo del kernel. Solitamente, passato il loro rilascio
+iniziale, i kernel ricevono aggiornamenti per più di un ciclo di sviluppo.
+Quindi, per esempio, la storia del kernel 4.13 appare così:
+
+ ============== ===============================
+ Settembre 3 4.13 rilascio stabile
+ Settembre 13 4.13.1
+ Settembre 20 4.13.2
+ Settembre 27 4.13.3
+ Ottobre 5 4.13.4
+ Ottobre 12 4.13.5
+ ... ...
+ Novembre 24 4.13.16
+ ============== ===============================
+
+La 4.13.16 fu l'aggiornamento finale per la versione 4.13.
+
+Alcuni kernel sono destinati ad essere kernel a "lungo termine"; questi
+riceveranno assistenza per un lungo periodo di tempo. Al momento in cui
+scriviamo, i manutentori dei kernel stabili a lungo termine sono:
+
+ ====== ====================== ==========================================
+ 3.16 Ben Hutchings (kernel stabile molto più a lungo termine)
+ 4.1 Sasha Levin
+ 4.4 Greg Kroah-Hartman (kernel stabile molto più a lungo termine)
+ 4.9 Greg Kroah-Hartman
+ 4.14 Greg Kroah-Hartman
+ ====== ====================== ==========================================
+
+
+Questa selezione di kernel di lungo periodo sono puramente dovuti ai loro
+manutentori, alla loro necessità e al tempo per tenere aggiornate proprio
+quelle versioni. Non ci sono altri kernel a lungo termine in programma per
+alcun rilascio in arrivo.
+
+Il ciclo di vita di una patch
+-----------------------------
+
+Le patch non passano direttamente dalla tastiera dello sviluppatori
+al ramo principale del kernel. Esiste, invece, una procedura disegnata
+per assicurare che ogni patch sia di buona qualità e desiderata nel
+ramo principale. Questo processo avviene velocemente per le correzioni
+meno importanti, o, nel caso di patch ampie e controverse, va avanti per anni.
+Per uno sviluppatore la maggior frustrazione viene dalla mancanza di
+comprensione di questo processo o dai tentativi di aggirarlo.
+
+Nella speranza di ridurre questa frustrazione, questo documento spiegherà
+come una patch viene inserita nel kernel. Ciò che segue è un'introduzione
+che descrive il processo ideale. Approfondimenti verranno invece trattati
+più avanti.
+
+Una patch attraversa, generalmente, le seguenti fasi:
+
+ - Progetto. In questa fase sono stabilite quelli che sono i requisiti
+ della modifica - e come verranno soddisfatti. Il lavoro di progettazione
+ viene spesso svolto senza coinvolgere la comunità, ma è meglio renderlo
+ il più aperto possibile; questo può far risparmiare molto tempo evitando
+ eventuali riprogettazioni successive.
+
+ - Prima revisione. Le patch vengono pubblicate sulle liste di discussione
+ interessate, e gli sviluppatori in quella lista risponderanno coi loro
+ commenti. Se si svolge correttamente, questo procedimento potrebbe far
+ emergere problemi rilevanti in una patch.
+
+ - Revisione più ampia. Quando la patch è quasi pronta per essere inserita
+ nel ramo principale, un manutentore importante del sottosistema dovrebbe
+ accettarla - anche se, questa accettazione non è una garanzia che la
+ patch arriverà nel ramo principale. La patch sarà visibile nei sorgenti
+ del sottosistema in questione e nei sorgenti -next (descritti sotto).
+ Quando il processo va a buon fine, questo passo porta ad una revisione
+ più estesa della patch e alla scoperta di problemi d'integrazione
+ con il lavoro altrui.
+
+- Per favore, tenete da conto che la maggior parte dei manutentori ha
+ anche un lavoro quotidiano, quindi integrare le vostre patch potrebbe
+ non essere la loro priorità più alta. Se una vostra patch riceve
+ dei suggerimenti su dei cambiamenti necessari, dovreste applicare
+ quei cambiamenti o giustificare perché non sono necessari. Se la vostra
+ patch non riceve alcuna critica ma non è stata integrata dal
+ manutentore del driver o sottosistema, allora dovreste continuare con
+ i necessari aggiornamenti per mantenere la patch aggiornata al kernel
+ più recente cosicché questa possa integrarsi senza problemi; continuate
+ ad inviare gli aggiornamenti per essere revisionati e integrati.
+
+ - Inclusione nel ramo principale. Eventualmente, una buona patch verrà
+ inserita all'interno nel repositorio principale, gestito da
+ Linus Torvalds. In questa fase potrebbero emergere nuovi problemi e/o
+ commenti; è importante che lo sviluppatore sia collaborativo e che sistemi
+ ogni questione che possa emergere.
+
+ - Rilascio stabile. Ora, il numero di utilizzatori che sono potenzialmente
+ toccati dalla patch è aumentato, quindi, ancora una volta, potrebbero
+ emergere nuovi problemi.
+
+ - Manutenzione di lungo periodo. Nonostante sia possibile che uno sviluppatore
+ si dimentichi del codice dopo la sua integrazione, questo comportamento
+ lascia una brutta impressione nella comunità di sviluppo. Integrare il
+ codice elimina alcuni degli oneri facenti parte della manutenzione, in
+ particolare, sistemerà le problematiche causate dalle modifiche all'API.
+ Ma lo sviluppatore originario dovrebbe continuare ad assumersi la
+ responsabilità per il codice se quest'ultimo continua ad essere utile
+ nel lungo periodo.
+
+Uno dei più grandi errori fatti dagli sviluppatori kernel (o dai loro datori
+di lavoro) è quello di cercare di ridurre tutta la procedura ad una singola
+"integrazione nel remo principale". Questo approccio inevitabilmente conduce
+a una condizione di frustrazione per tutti coloro che sono coinvolti.
+
+Come le modifiche finiscono nel Kernel
+--------------------------------------
+
+Esiste una sola persona che può inserire le patch nel repositorio principale
+del kernel: Linus Torvalds. Ma, di tutte le 9500 patch che entrarono nella
+versione 2.6.38 del kernel, solo 112 (circa l'1,3%) furono scelte direttamente
+da Linus in persona. Il progetto del kernel è cresciuto fino a raggiungere
+una dimensione tale per cui un singolo sviluppatore non può controllare e
+selezionare indipendentemente ogni modifica senza essere supportato.
+La via scelta dagli sviluppatori per indirizzare tale crescita è stata quella
+di utilizzare un sistema di "sottotenenti" basato sulla fiducia.
+
+Il codice base del kernel è spezzato in una serie si sottosistemi: rete,
+supporto per specifiche architetture, gestione della memoria, video e
+strumenti, etc. Molti sottosistemi hanno un manutentore designato: ovvero uno
+sviluppatore che ha piena responsabilità di tutto il codice presente in quel
+sottosistema. Tali manutentori di sottosistema sono i guardiani
+(in un certo senso) della parte di kernel che gestiscono; sono coloro che
+(solitamente) accetteranno una patch per l'inclusione nel ramo principale
+del kernel.
+
+I manutentori di sottosistema gestiscono ciascuno la propria parte dei sorgenti
+del kernel, utilizzando abitualmente (ma certamente non sempre) git.
+Strumenti come git (e affini come quilt o mercurial) permettono ai manutentori
+di stilare una lista delle patch, includendo informazioni sull'autore ed
+altri metadati. In ogni momento, il manutentore può individuare quale patch
+nel sua repositorio non si trova nel ramo principale.
+
+Quando la "finestra di integrazione" si apre, i manutentori di alto livello
+chiederanno a Linus di "prendere" dai loro repositori le modifiche che hanno
+selezionato per l'inclusione. Se Linus acconsente, il flusso di patch si
+convoglierà nel repositorio di quest ultimo, divenendo così parte del ramo
+principale del kernel. La quantità d'attenzione che Linus presta alle
+singole patch ricevute durante l'operazione di integrazione varia.
+È chiaro che, qualche volta, guardi più attentamente. Ma, come regola
+generale, Linus confida nel fatto che i manutentori di sottosistema non
+selezionino pessime patch.
+
+I manutentori di sottosistemi, a turno, possono "prendere" patch
+provenienti da altri manutentori. Per esempio, i sorgenti per la rete rete
+sono costruiti da modifiche che si sono accumulate inizialmente nei sorgenti
+dedicati ai driver per dispositivi di rete, rete senza fili, ecc. Tale
+catena di repositori può essere più o meno lunga, benché raramente ecceda
+i due o tre collegamenti. Questo processo è conosciuto come
+"la catena della fiducia", perché ogni manutentore all'interno della
+catena si fida di coloro che gestiscono i livelli più bassi.
+
+Chiaramente, in un sistema come questo, l'inserimento delle patch all'interno
+del kernel si basa sul trovare il manutentore giusto. Di norma, inviare
+patch direttamente a Linus non è la via giusta.
+
+
+Sorgenti -next
+--------------
+
+La catena di sottosistemi guida il flusso di patch all'interno del kernel,
+ma solleva anche un interessante quesito: se qualcuno volesse vedere tutte le
+patch pronte per la prossima finestra di integrazione?
+Gli sviluppatori si interesseranno alle patch in sospeso per verificare
+che non ci siano altri conflitti di cui preoccuparsi; una modifica che, per
+esempio, cambia il prototipo di una funzione fondamentale del kernel andrà in
+conflitto con qualsiasi altra modifica che utilizzi la vecchia versione di
+quella funzione. Revisori e tester vogliono invece avere accesso alle
+modifiche nella loro totalità prima che approdino nel ramo principale del
+kernel. Uno potrebbe prendere le patch provenienti da tutti i sottosistemi
+d'interesse, ma questo sarebbe un lavoro enorme e fallace.
+
+La risposta ci viene sotto forma di sorgenti -next, dove i sottosistemi sono
+raccolti per essere testati e controllati. Il più vecchio di questi sorgenti,
+gestito da Andrew Morton, è chiamato "-mm" (memory management, che è l'inizio
+di tutto). L'-mm integra patch proveniente da una lunga lista di sottosistemi;
+e ha, inoltre, alcune patch destinate al supporto del debugging.
+
+Oltre a questo, -mm contiene una raccolta significativa di patch che sono
+state selezionate da Andrew direttamente. Queste patch potrebbero essere
+state inviate in una lista di discussione, o possono essere applicate ad una
+parte del kernel per la quale non esiste un sottosistema dedicato.
+Di conseguenza, -mm opera come una specie di sottosistema "ultima spiaggia";
+se per una patch non esiste una via chiara per entrare nel ramo principale,
+allora è probabile che finirà in -mm. Le patch passate per -mm
+eventualmente finiranno nel sottosistema più appropriato o saranno inviate
+direttamente a Linus. In un tipico ciclo di sviluppo, circa il 5-10% delle
+patch andrà nel ramo principale attraverso -mm.
+
+La patch -mm correnti sono disponibili nella cartella "mmotm" (-mm of
+the moment) all'indirizzo:
+
+ http://www.ozlabs.org/~akpm/mmotm/
+
+È molto probabile che l'uso dei sorgenti MMOTM diventi un'esperienza
+frustrante; ci sono buone probabilità che non compili nemmeno.
+
+I sorgenti principali per il prossimo ciclo d'integrazione delle patch
+è linux-next, gestito da Stephen Rothwell. I sorgenti linux-next sono, per
+definizione, un'istantanea di come dovrà apparire il ramo principale dopo che
+la prossima finestra di inclusione si chiuderà. I linux-next sono annunciati
+sulla lista di discussione linux-kernel e linux-next nel momento in cui
+vengono assemblati; e possono essere scaricate da:
+
+ http://www.kernel.org/pub/linux/kernel/next/
+
+Linux-next è divenuto parte integrante del processo di sviluppo del kernel;
+tutte le patch incorporate durante una finestra di integrazione dovrebbero
+aver trovato la propria strada in linux-next, a volte anche prima dell'apertura
+della finestra di integrazione.
+
+
+Sorgenti in preparazione
+------------------------
+
+Nei sorgenti del kernel esiste la cartella drivers/staging/, dove risiedono
+molte sotto-cartelle per i driver o i filesystem che stanno per essere aggiunti
+al kernel. Questi restano nella cartella drivers/staging fintanto che avranno
+bisogno di maggior lavoro; una volta completato, possono essere spostate
+all'interno del kernel nel posto più appropriato. Questo è il modo di tener
+traccia dei driver che non sono ancora in linea con gli standard di codifica
+o qualità, ma che le persone potrebbero voler usare ugualmente e tracciarne
+lo sviluppo.
+
+Greg Kroah-Hartman attualmente gestisce i sorgenti in preparazione. I driver
+che non sono completamente pronti vengono inviati a lui, e ciascun driver avrà
+la propria sotto-cartella in drivers/staging/. Assieme ai file sorgenti
+dei driver, dovrebbe essere presente nella stessa cartella anche un file TODO.
+Il file TODO elenca il lavoro ancora da fare su questi driver per poter essere
+accettati nel kernel, e indica anche la lista di persone da inserire in copia
+conoscenza per ogni modifica fatta. Le regole attuali richiedono che i
+driver debbano, come minimo, compilare adeguatamente.
+
+La *preparazione* può essere una via relativamente facile per inserire nuovi
+driver all'interno del ramo principale, dove, con un po' di fortuna, saranno
+notati da altri sviluppatori e migliorati velocemente. Entrare nella fase
+di preparazione non è però la fine della storia, infatti, il codice che si
+trova nella cartella staging che non mostra regolari progressi potrebbe
+essere rimosso. Le distribuzioni, inoltre, tendono a dimostrarsi relativamente
+riluttanti nell'attivare driver in preparazione. Quindi lo preparazione è,
+nel migliore dei casi, una tappa sulla strada verso il divenire un driver
+del ramo principale.
+
+
+Strumenti
+---------
+
+Come è possibile notare dal testo sopra, il processo di sviluppo del kernel
+dipende pesantemente dalla capacità di guidare la raccolta di patch in
+diverse direzioni. L'intera cosa non funzionerebbe se non venisse svolta
+con l'uso di strumenti appropriati e potenti. Spiegare l'uso di tali
+strumenti non è lo scopo di questo documento, ma c'è spazio per alcuni
+consigli.
+
+In assoluto, nella comunità del kernel, predomina l'uso di git come sistema
+di gestione dei sorgenti. Git è una delle diverse tipologie di sistemi
+distribuiti di controllo versione che sono stati sviluppati nella comunità
+del software libero. Esso è calibrato per lo sviluppo del kernel, e si
+comporta abbastanza bene quando ha a che fare con repositori grandi e con un
+vasto numero di patch. Git ha inoltre la reputazione di essere difficile
+da imparare e utilizzare, benché stia migliorando. Agli sviluppatori
+del kernel viene richiesta un po' di familiarità con git; anche se non lo
+utilizzano per il proprio lavoro, hanno bisogno di git per tenersi al passo
+con il lavoro degli altri sviluppatori (e con il ramo principale).
+
+Git è ora compreso in quasi tutte le distribuzioni Linux. Esiste una sito che
+potete consultare:
+
+ http://git-scm.com/
+
+Qui troverete i riferimenti alla documentazione e alle guide passo-passo.
+
+Tra gli sviluppatori Kernel che non usano git, la scelta alternativa più
+popolare è quasi sicuramente Mercurial:
+
+ http://www.selenic.com/mercurial/
+
+Mercurial condivide diverse caratteristiche con git, ma fornisce
+un'interfaccia che potrebbe risultare più semplice da utilizzare.
+
+L'altro strumento che vale la pena conoscere è Quilt:
+
+ http://savannah.nongnu.org/projects/quilt/
+
+
+Quilt è un sistema di gestione delle patch, piuttosto che un sistema
+di gestione dei sorgenti. Non mantiene uno storico degli eventi; ma piuttosto
+è orientato verso il tracciamento di uno specifico insieme di modifiche
+rispetto ad un codice in evoluzione. Molti dei più grandi manutentori di
+sottosistema utilizzano quilt per gestire le patch che dovrebbero essere
+integrate. Per la gestione di certe tipologie di sorgenti (-mm, per esempio),
+quilt è il miglior strumento per svolgere il lavoro.
+
+
+Liste di discussione
+--------------------
+
+Una grossa parte del lavoro di sviluppo del Kernel Linux viene svolto tramite
+le liste di discussione. È difficile essere un membro della comunità
+pienamente coinvolto se non si partecipa almeno ad una lista da qualche
+parte. Ma, le liste di discussione di Linux rappresentano un potenziale
+problema per gli sviluppatori, che rischiano di venir sepolti da un mare di
+email, restare incagliati nelle convenzioni in vigore nelle liste Linux,
+o entrambi.
+
+Molte delle liste di discussione del Kernel girano su vger.kernel.org;
+l'elenco principale lo si trova sul sito:
+
+ http://vger.kernel.org/vger-lists.html
+
+Esistono liste gestite altrove; un certo numero di queste sono in
+lists.redhat.com.
+
+La lista di discussione principale per lo sviluppo del kernel è, ovviamente,
+linux-kernel. Questa lista è un luogo ostile dove trovarsi; i volumi possono
+raggiungere i 500 messaggi al giorno, la quantità di "rumore" è elevata,
+la conversazione può essere strettamente tecnica e i partecipanti non sono
+sempre preoccupati di mostrare un alto livello di educazione. Ma non esiste
+altro luogo dove la comunità di sviluppo del kernel si unisce per intero;
+gli sviluppatori che evitano tale lista si perderanno informazioni importanti.
+
+Ci sono alcuni consigli che possono essere utili per sopravvivere a
+linux-kernel:
+
+- Tenete la lista in una cartella separata, piuttosto che inserirla nella
+ casella di posta principale. Così da essere in grado di ignorare il flusso
+ di mail per un certo periodo di tempo.
+
+- Non cercate di seguire ogni conversazione - nessuno lo fa. È importante
+ filtrare solo gli argomenti d'interesse (sebbene va notato che le
+ conversazioni di lungo periodo possono deviare dall'argomento originario
+ senza cambiare il titolo della mail) e le persone che stanno partecipando.
+
+- Non alimentate i troll. Se qualcuno cerca di creare nervosismo, ignoratelo.
+
+- Quando rispondete ad una mail linux-kernel (o ad altre liste) mantenete
+ tutti i Cc:. In assenza di importanti motivazioni (come una richiesta
+ esplicita), non dovreste mai togliere destinatari. Assicuratevi sempre che
+ la persona alla quale state rispondendo sia presente nella lista Cc. Questa
+ usanza fa si che divenga inutile chiedere esplicitamente di essere inseriti
+ in copia nel rispondere al vostro messaggio.
+
+- Cercate nell'archivio della lista (e nella rete nella sua totalità) prima
+ di far domande. Molti sviluppatori possono divenire impazienti con le
+ persone che chiaramente non hanno svolto i propri compiti a casa.
+
+- Evitate il *top-posting* (cioè la pratica di mettere la vostra risposta sopra
+ alla frase alla quale state rispondendo). Ciò renderebbe la vostra risposta
+ difficile da leggere e genera scarsa impressione.
+
+- Chiedete nella lista di discussione corretta. Linux-kernel può essere un
+ punto di incontro generale, ma non è il miglior posto dove trovare
+ sviluppatori da tutti i sottosistemi.
+
+Infine, la ricerca della corretta lista di discussione è uno degli errori più
+comuni per gli sviluppatori principianti. Qualcuno che pone una domanda
+relativa alla rete su linux-kernel riceverà quasi certamente il suggerimento
+di chiedere sulla lista netdev, che è la lista frequentata dagli sviluppatori
+di rete. Ci sono poi altre liste per i sottosistemi SCSI, video4linux, IDE,
+filesystem, etc. Il miglior posto dove cercare una lista di discussione è il
+file MAINTAINERS che si trova nei sorgenti del kernel.
+
+Iniziare con lo sviluppo del Kernel
+-----------------------------------
+
+Sono comuni le domande sul come iniziare con lo sviluppo del kernel - sia da
+singole persone che da aziende. Altrettanto comuni sono i passi falsi che
+rendono l'inizio di tale relazione più difficile di quello che dovrebbe essere.
+
+Le aziende spesso cercano di assumere sviluppatori noti per creare un gruppo
+di sviluppo iniziale. Questo, in effetti, può essere una tecnica efficace.
+Ma risulta anche essere dispendiosa e non va ad accrescere il bacino di
+sviluppatori kernel con esperienza. È possibile anche "portare a casa"
+sviluppatori per accelerare lo sviluppo del kernel, dando comunque
+all'investimento un po' di tempo. Prendersi questo tempo può fornire
+al datore di lavoro un gruppo di sviluppatori che comprendono sia il kernel
+che l'azienda stessa, e che possono supportare la formazione di altre persone.
+Nel medio periodo, questa è spesso uno delle soluzioni più proficue.
+
+I singoli sviluppatori sono spesso, comprensibilmente, una perdita come punto
+di partenza. Iniziare con un grande progetto può rivelarsi intimidatorio;
+spesso all'inizio si vuole solo verificare il terreno con qualcosa di piccolo.
+Questa è una delle motivazioni per le quali molti sviluppatori saltano alla
+creazione di patch che vanno a sistemare errori di battitura o
+problematiche minori legate allo stile del codice. Sfortunatamente, tali
+patch creano un certo livello di rumore che distrae l'intera comunità di
+sviluppo, quindi, sempre di più, esse vengono degradate. I nuovi sviluppatori
+che desiderano presentarsi alla comunità non riceveranno l'accoglienza
+che vorrebbero con questi mezzi.
+
+Andrew Morton da questo consiglio agli aspiranti sviluppatori kernel
+
+::
+
+ Il primo progetto per un neofita del kernel dovrebbe essere
+ sicuramente quello di "assicurarsi che il kernel funzioni alla
+ perfezione sempre e su tutte le macchine sulle quali potete stendere
+ la vostra mano". Solitamente il modo per fare ciò è quello di
+ collaborare con gli altri nel sistemare le cose (questo richiede
+ persistenza!) ma va bene - è parte dello sviluppo kernel.
+
+(http://lwn.net/Articles/283982/).
+
+In assenza di problemi ovvi da risolvere, si consiglia agli sviluppatori
+di consultare, in generale, la lista di regressioni e di bachi aperti.
+Non c'è mai carenza di problematiche bisognose di essere sistemate;
+accollandosi tali questioni gli sviluppatori accumuleranno esperienza con
+la procedura, ed allo stesso tempo, aumenteranno la loro rispettabilità
+all'interno della comunità di sviluppo.