Documentation/translations/it_IT/process/howto.rst

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