1.. include:: ../disclaimer-ita.rst
2
3:Original: :ref:`Documentation/process/howto.rst <process_howto>`
4:Translator: Alessia Mantegazza <amantegazza@vaga.pv.it>
5
6.. _it_process_howto:
7
8Come partecipare allo sviluppo del kernel Linux
9===============================================
10
11Questo è il documento fulcro di quanto trattato sull'argomento.
12Esso contiene le istruzioni su come diventare uno sviluppatore
13del kernel Linux e spiega come lavorare con la comunità di
14sviluppo kernel Linux. Il documento non tratterà alcun aspetto
15tecnico relativo alla programmazione del kernel, ma vi aiuterà
16indirizzandovi sulla corretta strada.
17
18Se qualsiasi cosa presente in questo documento diventasse obsoleta,
19vi preghiamo di inviare le correzioni agli amministratori di questo
20file, indicati in fondo al presente documento.
21
22Introduzione
23------------
24Dunque, volete imparare come diventare sviluppatori del kernel Linux?
25O vi è stato detto dal vostro capo, "Vai, scrivi un driver Linux per
26questo dispositivo". Bene, l'obbiettivo di questo documento è quello
27di insegnarvi tutto ciò che dovete sapere per raggiungere il vostro
28scopo descrivendo il procedimento da seguire e consigliandovi
29su come lavorare con la comunità. Il documento cercherà, inoltre,
30di spiegare alcune delle ragioni per le quali la comunità lavora in un
31modo suo particolare.
32
33Il kernel è scritto prevalentemente nel linguaggio C con alcune parti
34specifiche dell'architettura scritte in linguaggio assembly.
35Per lo sviluppo kernel è richiesta una buona conoscenza del linguaggio C.
36L'assembly (di qualsiasi architettura) non è richiesto, a meno che non
37pensiate di fare dello sviluppo di basso livello per un'architettura.
38Sebbene essi non siano un buon sostituto ad un solido studio del
39linguaggio C o ad anni di esperienza, i seguenti libri sono, se non
40altro, utili riferimenti:
41
42- "The C Programming Language" di Kernighan e Ritchie [Prentice Hall]
43- "Practical C Programming" di Steve Oualline [O'Reilly]
44- "C:  A Reference Manual" di Harbison and Steele [Prentice Hall]
45
46Il kernel è stato scritto usando GNU C e la toolchain GNU.
47Sebbene si attenga allo standard ISO C89, esso utilizza una serie di
48estensioni che non sono previste in questo standard. Il kernel è un
49ambiente C indipendente, che non ha alcuna dipendenza dalle librerie
50C standard, così alcune parti del C standard non sono supportate.
51Le divisioni ``long long`` e numeri in virgola mobile non sono permessi.
52Qualche volta è difficile comprendere gli assunti che il kernel ha
53riguardo gli strumenti e le estensioni in uso, e sfortunatamente non
54esiste alcuna indicazione definitiva. Per maggiori informazioni, controllate,
55la pagina `info gcc`.
56
57Tenete a mente che state cercando di apprendere come lavorare con la comunità
58di sviluppo già esistente. Questo è un gruppo eterogeneo di persone, con alti
59standard di codifica, di stile e di procedura. Questi standard sono stati
60creati nel corso del tempo basandosi su quanto hanno riscontrato funzionare al
61meglio per un squadra così grande e geograficamente sparsa. Cercate di
62imparare, in anticipo, il più possibile circa questi standard, poichè ben
63spiegati; non aspettatevi che gli altri si adattino al vostro modo di fare
64o a quello della vostra azienda.
65
66Note legali
67------------
68Il codice sorgente del kernel Linux è rilasciato sotto GPL. Siete pregati
69di visionare il file, COPYING, presente nella cartella principale dei
70sorgente, per eventuali dettagli sulla licenza. Se avete ulteriori domande
71sulla licenza, contattate un avvocato, non chiedete sulle liste di discussione
72del kernel Linux. Le persone presenti in queste liste non sono avvocati,
73e non dovreste basarvi sulle loro dichiarazioni in materia giuridica.
74
75Per domande più frequenti e risposte sulla licenza GPL, guardare:
76
77	https://www.gnu.org/licenses/gpl-faq.html
78
79Documentazione
80--------------
81I sorgenti del kernel Linux hanno una vasta base di documenti che vi
82insegneranno come interagire con la comunità del kernel. Quando nuove
83funzionalità vengono aggiunte al kernel, si raccomanda di aggiungere anche i
84relativi file di documentatione che spiegano come usarele.
85Quando un cambiamento del kernel genera anche un cambiamento nell'interfaccia
86con lo spazio utente, è raccomandabile che inviate una notifica o una
87correzione alle pagine *man* spiegando tale modifica agli amministratori di
88queste pagine all'indirizzo mtk.manpages@gmail.com, aggiungendo
89in CC la lista linux-api@vger.kernel.org.
90
91Di seguito una lista di file che sono presenti nei sorgente del kernel e che
92è richiesto che voi leggiate:
93
94  :ref:`Documentation/translations/it_IT/admin-guide/README.rst <it_readme>`
95    Questo file da una piccola anteprima del kernel Linux e descrive il
96    minimo necessario per configurare e generare il kernel. I novizi
97    del kernel dovrebbero iniziare da qui.
98
99  :ref:`Documentation/translations/it_IT/process/changes.rst <it_changes>`
100
101    Questo file fornisce una lista dei pacchetti software necessari
102    a compilare e far funzionare il kernel con successo.
103
104  :ref:`Documentation/translations/it_IT/process/coding-style.rst <it_codingstyle>`
105
106    Questo file descrive lo stile della codifica per il kernel Linux,
107    e parte delle motivazioni che ne sono alla base. Tutto il nuovo codice deve
108    seguire le linee guida in questo documento. Molti amministratori
109    accetteranno patch solo se queste osserveranno tali regole, e molte
110    persone revisioneranno il codice solo se scritto nello stile appropriato.
111
112  :ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`
113
114    Questo file descrive dettagliatamente come creare ed inviare una patch
115    con successo, includendo (ma non solo questo):
116
117       - Contenuto delle email
118       - Formato delle email
119       - I destinatari delle email
120
121    Seguire tali regole non garantirà il successo (tutte le patch sono soggette
122    a controlli realitivi a contenuto e stile), ma non seguirle lo precluderà
123    sempre.
124
125    Altre ottime descrizioni di come creare buone patch sono:
126
127	"The Perfect Patch"
128		https://www.ozlabs.org/~akpm/stuff/tpp.txt
129
130	"Linux kernel patch submission format"
131		https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html
132
133  :ref:`Documentation/translations/it_IT/process/stable-api-nonsense.rst <it_stable_api_nonsense>`
134
135    Questo file descrive la motivazioni sottostanti la conscia decisione di
136    non avere un API stabile all'interno del kernel, incluso cose come:
137
138      - Sottosistemi shim-layers (per compatibilità?)
139      - Portabilità fra Sistemi Operativi dei driver.
140      - Attenuare i rapidi cambiamenti all'interno dei sorgenti del kernel
141        (o prevenirli)
142
143    Questo documento è vitale per la comprensione della filosifia alla base
144    dello sviluppo di Linux ed è molto importante per le persone che arrivano
145    da esperienze con altri Sistemi Operativi.
146
147  :ref:`Documentation/translations/it_IT/admin-guide/security-bugs.rst <it_securitybugs>`
148    Se ritenete di aver trovato un problema di sicurezza nel kernel Linux,
149    seguite i passaggi scritti in questo documento per notificarlo agli
150    sviluppatori del kernel, ed aiutare la risoluzione del problema.
151
152  :ref:`Documentation/translations/it_IT/process/management-style.rst <it_managementstyle>`
153    Questo documento descrive come i manutentori del kernel Linux operano
154    e la filosofia comune alla base del loro metodo.  Questa è un'importante
155    lettura per tutti coloro che sono nuovi allo sviluppo del kernel (o per
156    chi è semplicemente curioso), poiché risolve molti dei più comuni
157    fraintendimenti e confusioni dovuti al particolare comportamento dei
158    manutentori del kernel.
159
160  :ref:`Documentation/translations/it_IT/process/stable-kernel-rules.rst <it_stable_kernel_rules>`
161    Questo file descrive le regole sulle quali vengono basati i rilasci del
162    kernel, e spiega cosa fare se si vuole che una modifica venga inserita
163    in uno di questi rilasci.
164
165  :ref:`Documentation/translations/it_IT/process/kernel-docs.rst <it_kernel_docs>`
166    Una lista di documenti pertinenti allo sviluppo del kernel.
167    Per favore consultate questa lista se non trovate ciò che cercate nella
168    documentazione interna del kernel.
169
170  :ref:`Documentation/translations/it_IT/process/applying-patches.rst <it_applying_patches>`
171    Una buona introduzione che descrivere esattamente cos'è una patch e come
172    applicarla ai differenti rami di sviluppo del kernel.
173
174Il kernel inoltre ha un vasto numero di documenti che possono essere
175automaticamente generati dal codice sorgente stesso o da file
176ReStructuredText (ReST), come questo. Esso include una completa
177descrizione dell'API interna del kernel, e le regole su come gestire la
178sincronizzazione (locking) correttamente
179
180Tutte queste tipologie di documenti possono essere generati in PDF o in
181HTML utilizzando::
182
183	make pdfdocs
184	make htmldocs
185
186rispettivamente dalla cartella principale dei sorgenti del kernel.
187
188I documenti che impiegano ReST saranno generati nella cartella
189Documentation/output.
190Questi posso essere generati anche in formato LaTex e ePub con::
191
192	make latexdocs
193	make epubdocs
194
195Diventare uno sviluppatore del kernel
196-------------------------------------
197Se non sapete nulla sullo sviluppo del kernel Linux, dovreste dare uno
198sguardo al progetto *Linux KernelNewbies*:
199
200	https://kernelnewbies.org
201
202Esso prevede un'utile lista di discussione dove potete porre più o meno ogni
203tipo di quesito relativo ai concetti fondamentali sullo sviluppo del kernel
204(assicuratevi di cercare negli archivi, prima di chiedere qualcosa alla
205quale è già stata fornita risposta in passato). Esistono inoltre, un canale IRC
206che potete usare per formulare domande in tempo reale, e molti documenti utili
207che vi faciliteranno nell'apprendimento dello sviluppo del kernel Linux.
208
209Il sito internet contiene informazioni di base circa l'organizzazione del
210codice, sottosistemi e progetti attuali (sia interni che esterni a Linux).
211Esso descrive, inoltre, informazioni logistiche di base, riguardanti ad esempio
212la compilazione del kernel e l'applicazione di una modifica.
213
214Se non sapete dove cominciare, ma volete cercare delle attività dalle quali
215partire per partecipare alla comunità di sviluppo, andate al progetto Linux
216Kernel Janitor's.
217
218	https://kernelnewbies.org/KernelJanitors
219
220È un buon posto da cui iniziare. Esso presenta una lista di problematiche
221relativamente semplici da sistemare e pulire all'interno della sorgente del
222kernel Linux. Lavorando con gli sviluppatori incaricati di questo progetto,
223imparerete le basi per l'inserimento delle vostre modifiche all'interno dei
224sorgenti del kernel Linux, e possibilmente, sarete indirizzati al lavoro
225successivo da svolgere, se non ne avrete ancora idea.
226
227Prima di apportare una qualsiasi modifica al codice del kernel Linux,
228è imperativo comprendere come tale codice funziona. A questo scopo, non c'è
229nulla di meglio che leggerlo direttamente (la maggior parte dei bit più
230complessi sono ben commentati), eventualmente anche con l'aiuto di strumenti
231specializzati. Uno degli strumenti che è particolarmente raccomandato è
232il progetto Linux Cross-Reference, che è in grado di presentare codice
233sorgente in un formato autoreferenziale ed indicizzato. Un eccellente ed
234aggiornata fonte di consultazione del codice del kernel la potete trovare qui:
235
236	https://elixir.bootlin.com/
237
238
239Il processo di sviluppo
240-----------------------
241Il processo di sviluppo del kernel Linux si compone di pochi "rami" principali
242e di molti altri rami per specifici sottosistemi. Questi rami sono:
243
244  - I sorgenti kernel 4.x
245  - I sorgenti stabili del kernel 4.x.y -stable
246  - Sorgenti dei sottosistemi del kernel e le loro modifiche
247  - Il kernel 4.x -next per test d'integrazione
248
249I sorgenti kernel 4.x
250~~~~~~~~~~~~~~~~~~~~~
251
252I kernel 4.x sono amministrati da Linus Torvald, e possono essere trovati
253su https://kernel.org nella cartella pub/linux/kernel/v4.x/. Il processo
254di sviluppo è il seguente:
255
256  - Non appena un nuovo kernel viene rilasciato si apre una finestra di due
257    settimane. Durante questo periodo i manutentori possono proporre a Linus
258    dei grossi cambiamenti; solitamente i cambiamenti che sono già stati
259    inseriti nel ramo -next del kernel per alcune settimane. Il modo migliore
260    per sottoporre dei cambiamenti è attraverso git (lo strumento usato per
261    gestire i sorgenti del kernel, più informazioni sul sito
262    https://git-scm.com/) ma anche delle patch vanno bene.
263
264  - Al termine delle due settimane un kernel -rc1 viene rilasciato e
265    l'obbiettivo ora è quello di renderlo il più solido possibile. A questo
266    punto la maggior parte delle patch dovrebbero correggere un'eventuale
267    regressione. I bachi che sono sempre esistiti non sono considerabili come
268    regressioni, quindi inviate questo tipo di cambiamenti solo se sono
269    importanti. Notate che un intero driver (o filesystem) potrebbe essere
270    accettato dopo la -rc1 poiché non esistono rischi di una possibile
271    regressione con tale cambiamento, fintanto che quest'ultimo è
272    auto-contenuto e non influisce su aree esterne al codice che è stato
273    aggiunto. git può essere utilizzato per inviare le patch a Linus dopo che
274    la -rc1 è stata rilasciata, ma è anche necessario inviare le patch ad
275    una lista di discussione pubblica per un'ulteriore revisione.
276
277  - Una nuova -rc viene rilasciata ogni volta che Linus reputa che gli attuali
278    sorgenti siano in uno stato di salute ragionevolmente adeguato ai test.
279    L'obiettivo è quello di rilasciare una nuova -rc ogni settimana.
280
281  - Il processo continua fino a che il kernel è considerato "pronto"; tale
282    processo dovrebbe durare circa in 6 settimane.
283
284È utile menzionare quanto scritto da Andrew Morton sulla lista di discussione
285kernel-linux in merito ai rilasci del kernel:
286
287	*"Nessuno sa quando un kernel verrà rilasciato, poichè questo è
288	legato allo stato dei bachi e non ad una cronologia preventiva."*
289
290I sorgenti stabili del kernel 4.x.y -stable
291~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
292
293I kernel con versioni in 3-parti sono "kernel stabili". Essi contengono
294correzioni critiche relativamente piccole nell'ambito della sicurezza
295oppure significative regressioni scoperte in un dato 4.x kernel.
296
297Questo è il ramo raccomandato per gli utenti che vogliono un kernel recente
298e stabile e non sono interessati a dare il proprio contributo alla verifica
299delle versioni di sviluppo o sperimentali.
300
301Se non è disponibile alcun kernel 4.x.y., quello più aggiornato e stabile
302sarà il kernel 4.x con la numerazione più alta.
303
3044.x.y sono amministrati dal gruppo "stable" <stable@vger.kernel.org>, e sono
305rilasciati a seconda delle esigenze. Il normale periodo di rilascio è
306approssimativamente di due settimane, ma può essere più lungo se non si
307verificano problematiche urgenti. Un problema relativo alla sicurezza, invece,
308può determinare un rilascio immediato.
309
310Il file Documentation/process/stable-kernel-rules.rst (nei sorgenti) documenta
311quali tipologie di modifiche sono accettate per i sorgenti -stable, e come
312avviene il processo di rilascio.
313
314
315Sorgenti dei sottosistemi del kernel e le loro patch
316~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
317
318I manutentori dei diversi sottosistemi del kernel --- ed anche molti
319sviluppatori di sottosistemi --- mostrano il loro attuale stato di sviluppo
320nei loro repositori. In questo modo, altri possono vedere cosa succede nelle
321diverse parti del kernel. In aree dove lo sviluppo è rapido, potrebbe essere
322chiesto ad uno sviluppatore di basare le proprie modifiche su questi repositori
323in modo da evitare i conflitti fra le sottomissioni ed altri lavori in corso
324
325La maggior parte di questi repositori sono git, ma esistono anche altri SCM
326in uso, o file di patch pubblicate come una serie quilt.
327Gli indirizzi dei repositori di sottosistema sono indicati nel file
328MAINTAINERS.  Molti di questi posso essere trovati su  https://git.kernel.org/.
329
330Prima che una modifica venga inclusa in questi sottosistemi, sarà soggetta ad
331una revisione che inizialmente avviene tramite liste di discussione (vedere la
332sezione dedicata qui sotto). Per molti sottosistemi del kernel, tale processo
333di revisione è monitorato con lo strumento patchwork.
334Patchwork offre un'interfaccia web che mostra le patch pubblicate, inclusi i
335commenti o le revisioni fatte, e gli amministratori possono indicare le patch
336come "in revisione", "accettate", o "rifiutate". Diversi siti Patchwork sono
337elencati al sito https://patchwork.kernel.org/.
338
339Il kernel 4.x -next per test d'integrazione
340~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
341
342Prima che gli aggiornamenti dei sottosistemi siano accorpati nel ramo
343principale 4.x, sarà necessario un test d'integrazione.
344A tale scopo, esiste un repositorio speciale di test nel quale virtualmente
345tutti i rami dei sottosistemi vengono inclusi su base quotidiana:
346
347	https://git.kernel.org/?p=linux/kernel/git/next/linux-next.git
348
349In questo modo, i kernel -next offrono uno sguardo riassuntivo su quello che
350ci si aspetterà essere nel kernel principale nel successivo periodo
351d'incorporazione.
352Coloro che vorranno fare dei test d'esecuzione del kernel -next sono più che
353benvenuti.
354
355
356Riportare Bug
357-------------
358
359Il file 'Documentation/admin-guide/reporting-issues.rst' nella
360cartella principale del kernel spiega come segnalare un baco nel
361kernel, e fornisce dettagli su quali informazioni sono necessarie agli
362sviluppatori del kernel per poter studiare il problema.
363
364Gestire i rapporti sui bug
365--------------------------
366
367Uno dei modi migliori per mettere in pratica le vostre capacità di hacking è
368quello di riparare bachi riportati da altre persone. Non solo aiuterete a far
369diventare il kernel più stabile, ma imparerete a riparare problemi veri dal
370mondo ed accrescerete le vostre competenze, e gli altri sviluppatori saranno
371al corrente della vostra presenza. Riparare bachi è una delle migliori vie per
372acquisire meriti tra gli altri sviluppatori, perchè non a molte persone piace
373perdere tempo a sistemare i bachi di altri.
374
375Per lavorare sui bachi già segnalati, per prima cosa cercate il
376sottosistema che vi interessa. Poi, verificate nel file MAINTAINERS
377dove vengono collezionati solitamente i bachi per quel sottosistema;
378spesso sarà una lista di discussione, raramente un bugtracker. Cercate
379bachi nell'archivio e aiutate dove credete di poterlo fare. Potete
380anche consultare https://bugzilla.kernel.org; però, solo una manciata di
381sottosistemi lo usano attivamente, ciò nonostante i bachi che
382coinvolgono l'intero kernel sono sempre riportati lì.
383
384Liste di discussione
385--------------------
386
387Come descritto in molti dei documenti qui sopra, la maggior parte degli
388sviluppatori del kernel partecipano alla lista di discussione Linux Kernel.
389I dettagli su come iscriversi e disiscriversi dalla lista possono essere
390trovati al sito:
391
392	http://vger.kernel.org/vger-lists.html#linux-kernel
393
394Ci sono diversi archivi della lista di discussione. Usate un qualsiasi motore
395di ricerca per trovarli. Per esempio:
396
397	http://dir.gmane.org/gmane.linux.kernel
398
399É caldamente consigliata una ricerca in questi archivi sul tema che volete
400sollevare, prima di pubblicarlo sulla lista. Molte cose sono già state
401discusse in dettaglio e registrate negli archivi della lista di discussione.
402
403Molti dei sottosistemi del kernel hanno anche una loro lista di discussione
404dedicata.  Guardate nel file MAINTAINERS per avere una lista delle liste di
405discussione e il loro uso.
406
407Molte di queste liste sono gestite su kernel.org. Per informazioni consultate
408la seguente pagina:
409
410	http://vger.kernel.org/vger-lists.html
411
412Per favore ricordatevi della buona educazione quando utilizzate queste liste.
413Sebbene sia un pò dozzinale, il seguente URL contiene alcune semplici linee
414guida per interagire con la lista (o con qualsiasi altra lista):
415
416	http://www.albion.com/netiquette/
417
418Se diverse persone rispondo alla vostra mail, la lista dei riceventi (copia
419conoscenza) potrebbe diventare abbastanza lunga. Non cancellate nessuno dalla
420lista di CC: senza un buon motivo, e non rispondete solo all'indirizzo
421della lista di discussione. Fateci l'abitudine perché capita spesso di
422ricevere la stessa email due volte: una dal mittente ed una dalla lista; e non
423cercate di modificarla aggiungendo intestazioni stravaganti, agli altri non
424piacerà.
425
426Ricordate di rimanere sempre in argomento e di mantenere le attribuzioni
427delle vostre risposte invariate; mantenete il "John Kernelhacker wrote ...:"
428in cima alla vostra replica e aggiungete le vostre risposte fra i singoli
429blocchi citati, non scrivete all'inizio dell'email.
430
431Se aggiungete patch alla vostra mail, assicuratevi che siano del tutto
432leggibili come indicato in Documentation/process/submitting-patches.rst.
433Gli sviluppatori kernel non vogliono avere a che fare con allegati o patch
434compresse; vogliono invece poter commentare le righe dei vostri cambiamenti,
435il che può funzionare solo in questo modo.
436Assicuratevi di utilizzare un gestore di mail che non alterì gli spazi ed i
437caratteri. Un ottimo primo test è quello di inviare a voi stessi una mail e
438cercare di sottoporre la vostra stessa patch. Se non funziona, sistemate il
439vostro programma di posta, o cambiatelo, finché non funziona.
440
441Ed infine, per favore ricordatevi di mostrare rispetto per gli altri
442sottoscriventi.
443
444Lavorare con la comunità
445------------------------
446
447L'obiettivo di questa comunità è quello di fornire il miglior kernel possibile.
448Quando inviate una modifica che volete integrare, sarà valutata esclusivamente
449dal punto di vista tecnico. Quindi, cosa dovreste aspettarvi?
450
451  - critiche
452  - commenti
453  - richieste di cambiamento
454  - richieste di spiegazioni
455  - nulla
456
457Ricordatevi che questo fa parte dell'integrazione della vostra modifica
458all'interno del kernel.  Dovete essere in grado di accettare le critiche,
459valutarle a livello tecnico ed eventualmente rielaborare nuovamente le vostre
460modifiche o fornire delle chiare e concise motivazioni per le quali le
461modifiche suggerite non dovrebbero essere fatte.
462Se non riceverete risposte, aspettate qualche giorno e riprovate ancora,
463qualche volta le cose si perdono nell'enorme mucchio di email.
464
465Cosa non dovreste fare?
466
467  - aspettarvi che la vostra modifica venga accettata senza problemi
468  - mettervi sulla difensiva
469  - ignorare i commenti
470  - sottomettere nuovamente la modifica senza fare nessuno dei cambiamenti
471    richiesti
472
473In una comunità che è alla ricerca delle migliori soluzioni tecniche possibili,
474ci saranno sempre opinioni differenti sull'utilità di una modifica.
475Siate cooperativi e vogliate adattare la vostra idea in modo che sia inserita
476nel kernel.  O almeno vogliate dimostrare che la vostra idea vale.
477Ricordatevi, sbagliare è accettato fintanto che siate disposti a lavorare verso
478una soluzione che è corretta.
479
480È normale che le risposte alla vostra prima modifica possa essere
481semplicemente una lista con dozzine di cose che dovreste correggere.
482Questo **non** implica che la vostra patch non sarà accettata, e questo
483**non** è contro di voi personalmente.
484Semplicemente correggete tutte le questioni sollevate contro la vostra modifica
485ed inviatela nuovamente.
486
487Differenze tra la comunità del kernel e le strutture aziendali
488--------------------------------------------------------------
489
490La comunità del kernel funziona diversamente rispetto a molti ambienti di
491sviluppo aziendali.  Qui di seguito una lista di cose che potete provare a
492fare per evitare problemi:
493
494  Cose da dire riguardanti le modifiche da voi proposte:
495
496  - "Questo risolve più problematiche."
497  - "Questo elimina 2000 stringhe di codice."
498  - "Qui una modifica che spiega cosa sto cercando di fare."
499  - "L'ho testato su 5 diverse architetture.."
500  - "Qui una serie di piccole modifiche che.."
501  - "Questo aumenta le prestazioni di macchine standard..."
502
503 Cose che dovreste evitare di dire:
504
505    - "Lo abbiamo fatto in questo modo in AIX/ptx/Solaris, di conseguenza
506       deve per forza essere giusto..."
507    - "Ho fatto questo per 20 anni, quindi.."
508    - "Questo è richiesto dalla mia Azienda per far soldi"
509    - "Questo è per la linea di prodotti della nostra Azienda"
510    - "Ecco il mio documento di design di 1000 pagine che descrive ciò che ho
511       in mente"
512    - "Ci ho lavorato per 6 mesi..."
513    - "Ecco una patch da 5000 righe che.."
514    - "Ho riscritto il pasticcio attuale, ed ecco qua.."
515    - "Ho una scadenza, e questa modifica ha bisogno di essere approvata ora"
516
517Un'altra cosa nella quale la comunità del kernel si differenzia dai più
518classici ambienti di ingegneria del software è la natura "senza volto" delle
519interazioni umane. Uno dei benefici dell'uso delle email e di irc come forma
520primordiale di comunicazione è l'assenza di discriminazione basata su genere e
521razza. L'ambienti di lavoro Linux accetta donne e minoranze perchè tutto quello
522che sei è un indirizzo email.  Aiuta anche l'aspetto internazionale nel
523livellare il terreno di gioco perchè non è possibile indovinare il genere
524basandosi sul nome di una persona. Un uomo può chiamarsi Andrea ed una donna
525potrebbe chiamarsi Pat. Gran parte delle donne che hanno lavorato al kernel
526Linux e che hanno espresso una personale opinione hanno avuto esperienze
527positive.
528
529La lingua potrebbe essere un ostacolo per quelle persone che non si trovano
530a loro agio con l'inglese.  Una buona padronanza del linguaggio può essere
531necessaria per esporre le proprie idee in maniera appropiata all'interno
532delle liste di discussione, quindi è consigliabile che rileggiate le vostre
533email prima di inviarle in modo da essere certi che abbiano senso in inglese.
534
535
536Spezzare le vostre modifiche
537----------------------------
538
539La comunità del kernel Linux non accetta con piacere grossi pezzi di codice
540buttati lì tutti in una volta. Le modifiche necessitano di essere
541adeguatamente presentate, discusse, e suddivise in parti più piccole ed
542indipendenti.  Questo è praticamente l'esatto opposto di quello che le
543aziende fanno solitamente.  La vostra proposta dovrebbe, inoltre, essere
544presentata prestissimo nel processo di sviluppo, così che possiate ricevere
545un riscontro su quello che state facendo. Lasciate che la comunità
546senta che state lavorando con loro, e che non li stiate sfruttando come
547discarica per le vostre aggiunte.  In ogni caso, non inviate 50 email nello
548stesso momento in una lista di discussione, il più delle volte la vostra serie
549di modifiche dovrebbe essere più piccola.
550
551I motivi per i quali dovreste frammentare le cose sono i seguenti:
552
5531) Piccole modifiche aumentano le probabilità che vengano accettate,
554   altrimenti richiederebbe troppo tempo o sforzo nel verificarne
555   la correttezza.  Una modifica di 5 righe può essere accettata da un
556   manutentore con a mala pena una seconda occhiata. Invece, una modifica da
557   500 linee può richiedere ore di rilettura per verificarne la correttezza
558   (il tempo necessario è esponenzialmente proporzionale alla dimensione della
559   modifica, o giù di lì)
560
561   Piccole modifiche sono inoltre molto facili da debuggare quando qualcosa
562   non va. È molto più facile annullare le modifiche una per una che
563   dissezionare una patch molto grande dopo la sua sottomissione (e rompere
564   qualcosa).
565
5662) È importante non solo inviare piccole modifiche, ma anche riscriverle e
567   semplificarle (o più semplicemente ordinarle) prima di sottoporle.
568
569Qui un'analogia dello sviluppatore kernel Al Viro:
570
571	*"Pensate ad un insegnante di matematica che corregge il compito
572	di uno studente (di matematica). L'insegnante non vuole vedere le
573	prove e gli errori commessi dallo studente prima che arrivi alla
574	soluzione. Vuole vedere la risposta più pulita ed elegante
575	possibile.  Un buono studente lo sa, e non presenterebbe mai le
576	proprie bozze prima prima della soluzione finale"*
577
578	*"Lo stesso vale per lo sviluppo del kernel. I manutentori ed i
579	revisori non vogliono vedere il procedimento che sta dietro al
580	problema che uno sta risolvendo. Vogliono vedere una soluzione
581	semplice ed elegante."*
582
583Può essere una vera sfida il saper mantenere l'equilibrio fra una presentazione
584elegante della vostra soluzione, lavorare insieme ad una comunità e dibattere
585su un lavoro incompleto.  Pertanto è bene entrare presto nel processo di
586revisione per migliorare il vostro lavoro, ma anche per riuscire a tenere le
587vostre modifiche in pezzettini che potrebbero essere già accettate, nonostante
588la vostra intera attività non lo sia ancora.
589
590In fine, rendetevi conto che non è accettabile inviare delle modifiche
591incomplete con la promessa che saranno "sistemate dopo".
592
593
594Giustificare le vostre modifiche
595--------------------------------
596
597Insieme alla frammentazione delle vostre modifiche, è altrettanto importante
598permettere alla comunità Linux di capire perché dovrebbero accettarle.
599Nuove funzionalità devono essere motivate come necessarie ed utili.
600
601
602Documentare le vostre modifiche
603-------------------------------
604
605Quando inviate le vostre modifiche, fate particolare attenzione a quello che
606scrivete nella vostra email.  Questa diventerà il *ChangeLog* per la modifica,
607e sarà visibile a tutti per sempre.  Dovrebbe descrivere la modifica nella sua
608interezza, contenendo:
609
610 - perchè la modifica è necessaria
611 - l'approccio d'insieme alla patch
612 - dettagli supplementari
613 - risultati dei test
614
615Per maggiori dettagli su come tutto ciò dovrebbe apparire, riferitevi alla
616sezione ChangeLog del documento:
617
618 "The Perfect Patch"
619      http://www.ozlabs.org/~akpm/stuff/tpp.txt
620
621A volte tutto questo è difficile da realizzare. Il perfezionamento di queste
622pratiche può richiedere anni (eventualmente). È un processo continuo di
623miglioramento che richiede molta pazienza e determinazione. Ma non mollate,
624si può fare. Molti lo hanno fatto prima, ed ognuno ha dovuto iniziare dove
625siete voi ora.
626
627
628
629
630----------
631
632Grazie a Paolo Ciarrocchi che ha permesso che la sezione "Development Process"
633(https://lwn.net/Articles/94386/) fosse basata sui testi da lui scritti, ed a
634Randy Dunlap e Gerrit Huizenga per la lista di cose che dovreste e non
635dovreste dire. Grazie anche a Pat Mochel, Hanna Linder, Randy Dunlap,
636Kay Sievers, Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook, Andrew Morton,
637Andi Kleen, Vadim Lobanov, Jesper Juhl, Adrian Bunk, Keri Harris, Frans Pop,
638David A. Wheeler, Junio Hamano, Michael Kerrisk, e Alex Shepard per le
639loro revisioni, commenti e contributi.  Senza il loro aiuto, questo documento
640non sarebbe stato possibile.
641
642Manutentore: Greg Kroah-Hartman <greg@kroah.com>
643