howto.rst (30751B)
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>` 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 https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html 133 134 :ref:`Documentation/translations/it_IT/process/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 175Il kernel inoltre ha un vasto numero di documenti che possono essere 176automaticamente generati dal codice sorgente stesso o da file 177ReStructuredText (ReST), come questo. Esso include una completa 178descrizione dell'API interna del kernel, e le regole su come gestire la 179sincronizzazione (locking) correttamente 180 181Tutte queste tipologie di documenti possono essere generati in PDF o in 182HTML utilizzando:: 183 184 make pdfdocs 185 make htmldocs 186 187rispettivamente dalla cartella principale dei sorgenti del kernel. 188 189I documenti che impiegano ReST saranno generati nella cartella 190Documentation/output. 191Questi posso essere generati anche in formato LaTex e ePub con:: 192 193 make latexdocs 194 make epubdocs 195 196Diventare uno sviluppatore del kernel 197------------------------------------- 198Se non sapete nulla sullo sviluppo del kernel Linux, dovreste dare uno 199sguardo al progetto *Linux KernelNewbies*: 200 201 https://kernelnewbies.org 202 203Esso prevede un'utile lista di discussione dove potete porre più o meno ogni 204tipo di quesito relativo ai concetti fondamentali sullo sviluppo del kernel 205(assicuratevi di cercare negli archivi, prima di chiedere qualcosa alla 206quale è già stata fornita risposta in passato). Esistono inoltre, un canale IRC 207che potete usare per formulare domande in tempo reale, e molti documenti utili 208che vi faciliteranno nell'apprendimento dello sviluppo del kernel Linux. 209 210Il sito internet contiene informazioni di base circa l'organizzazione del 211codice, sottosistemi e progetti attuali (sia interni che esterni a Linux). 212Esso descrive, inoltre, informazioni logistiche di base, riguardanti ad esempio 213la compilazione del kernel e l'applicazione di una modifica. 214 215Se non sapete dove cominciare, ma volete cercare delle attività dalle quali 216partire per partecipare alla comunità di sviluppo, andate al progetto Linux 217Kernel Janitor's. 218 219 https://kernelnewbies.org/KernelJanitors 220 221È un buon posto da cui iniziare. Esso presenta una lista di problematiche 222relativamente semplici da sistemare e pulire all'interno della sorgente del 223kernel Linux. Lavorando con gli sviluppatori incaricati di questo progetto, 224imparerete le basi per l'inserimento delle vostre modifiche all'interno dei 225sorgenti del kernel Linux, e possibilmente, sarete indirizzati al lavoro 226successivo da svolgere, se non ne avrete ancora idea. 227 228Prima di apportare una qualsiasi modifica al codice del kernel Linux, 229è imperativo comprendere come tale codice funziona. A questo scopo, non c'è 230nulla di meglio che leggerlo direttamente (la maggior parte dei bit più 231complessi sono ben commentati), eventualmente anche con l'aiuto di strumenti 232specializzati. Uno degli strumenti che è particolarmente raccomandato è 233il progetto Linux Cross-Reference, che è in grado di presentare codice 234sorgente in un formato autoreferenziale ed indicizzato. Un eccellente ed 235aggiornata fonte di consultazione del codice del kernel la potete trovare qui: 236 237 https://elixir.bootlin.com/ 238 239 240Il processo di sviluppo 241----------------------- 242Il processo di sviluppo del kernel Linux si compone di pochi "rami" principali 243e 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 - Sorgenti dei sottosistemi del kernel e le loro modifiche 248 - Il kernel 4.x -next per test d'integrazione 249 250I sorgenti kernel 4.x 251~~~~~~~~~~~~~~~~~~~~~ 252 253I kernel 4.x sono amministrati da Linus Torvald, e possono essere trovati 254su https://kernel.org nella cartella pub/linux/kernel/v4.x/. Il processo 255di sviluppo è il seguente: 256 257 - Non appena un nuovo kernel viene rilasciato si apre una finestra di due 258 settimane. Durante questo periodo i manutentori possono proporre a Linus 259 dei grossi cambiamenti; solitamente i cambiamenti che sono già stati 260 inseriti nel ramo -next del kernel per alcune settimane. Il modo migliore 261 per sottoporre dei cambiamenti è attraverso git (lo strumento usato per 262 gestire i sorgenti del kernel, più informazioni sul sito 263 https://git-scm.com/) ma anche delle patch vanno bene. 264 265 - Al termine delle due settimane un kernel -rc1 viene rilasciato e 266 l'obbiettivo ora è quello di renderlo il più solido possibile. A questo 267 punto la maggior parte delle patch dovrebbero correggere un'eventuale 268 regressione. I bachi che sono sempre esistiti non sono considerabili come 269 regressioni, quindi inviate questo tipo di cambiamenti solo se sono 270 importanti. Notate che un intero driver (o filesystem) potrebbe essere 271 accettato dopo la -rc1 poiché non esistono rischi di una possibile 272 regressione con tale cambiamento, fintanto che quest'ultimo è 273 auto-contenuto e non influisce su aree esterne al codice che è stato 274 aggiunto. git può essere utilizzato per inviare le patch a Linus dopo che 275 la -rc1 è stata rilasciata, ma è anche necessario inviare le patch ad 276 una lista di discussione pubblica per un'ulteriore revisione. 277 278 - Una nuova -rc viene rilasciata ogni volta che Linus reputa che gli attuali 279 sorgenti siano in uno stato di salute ragionevolmente adeguato ai test. 280 L'obiettivo è quello di rilasciare una nuova -rc ogni settimana. 281 282 - Il processo continua fino a che il kernel è considerato "pronto"; tale 283 processo dovrebbe durare circa in 6 settimane. 284 285È utile menzionare quanto scritto da Andrew Morton sulla lista di discussione 286kernel-linux in merito ai rilasci del kernel: 287 288 *"Nessuno sa quando un kernel verrà rilasciato, poichè questo è 289 legato allo stato dei bachi e non ad una cronologia preventiva."* 290 291I sorgenti stabili del kernel 4.x.y -stable 292~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 293 294I kernel con versioni in 3-parti sono "kernel stabili". Essi contengono 295correzioni critiche relativamente piccole nell'ambito della sicurezza 296oppure significative regressioni scoperte in un dato 4.x kernel. 297 298Questo è il ramo raccomandato per gli utenti che vogliono un kernel recente 299e stabile e non sono interessati a dare il proprio contributo alla verifica 300delle versioni di sviluppo o sperimentali. 301 302Se non è disponibile alcun kernel 4.x.y., quello più aggiornato e stabile 303sarà il kernel 4.x con la numerazione più alta. 304 3054.x.y sono amministrati dal gruppo "stable" <stable@vger.kernel.org>, e sono 306rilasciati a seconda delle esigenze. Il normale periodo di rilascio è 307approssimativamente di due settimane, ma può essere più lungo se non si 308verificano problematiche urgenti. Un problema relativo alla sicurezza, invece, 309può determinare un rilascio immediato. 310 311Il file Documentation/process/stable-kernel-rules.rst (nei sorgenti) documenta 312quali tipologie di modifiche sono accettate per i sorgenti -stable, e come 313avviene il processo di rilascio. 314 315 316Sorgenti dei sottosistemi del kernel e le loro patch 317~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 318 319I manutentori dei diversi sottosistemi del kernel --- ed anche molti 320sviluppatori di sottosistemi --- mostrano il loro attuale stato di sviluppo 321nei loro repositori. In questo modo, altri possono vedere cosa succede nelle 322diverse parti del kernel. In aree dove lo sviluppo è rapido, potrebbe essere 323chiesto ad uno sviluppatore di basare le proprie modifiche su questi repositori 324in modo da evitare i conflitti fra le sottomissioni ed altri lavori in corso 325 326La maggior parte di questi repositori sono git, ma esistono anche altri SCM 327in uso, o file di patch pubblicate come una serie quilt. 328Gli indirizzi dei repositori di sottosistema sono indicati nel file 329MAINTAINERS. Molti di questi posso essere trovati su https://git.kernel.org/. 330 331Prima che una modifica venga inclusa in questi sottosistemi, sarà soggetta ad 332una revisione che inizialmente avviene tramite liste di discussione (vedere la 333sezione dedicata qui sotto). Per molti sottosistemi del kernel, tale processo 334di revisione è monitorato con lo strumento patchwork. 335Patchwork offre un'interfaccia web che mostra le patch pubblicate, inclusi i 336commenti o le revisioni fatte, e gli amministratori possono indicare le patch 337come "in revisione", "accettate", o "rifiutate". Diversi siti Patchwork sono 338elencati al sito https://patchwork.kernel.org/. 339 340Il kernel 4.x -next per test d'integrazione 341~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 342 343Prima che gli aggiornamenti dei sottosistemi siano accorpati nel ramo 344principale 4.x, sarà necessario un test d'integrazione. 345A tale scopo, esiste un repositorio speciale di test nel quale virtualmente 346tutti i rami dei sottosistemi vengono inclusi su base quotidiana: 347 348 https://git.kernel.org/?p=linux/kernel/git/next/linux-next.git 349 350In questo modo, i kernel -next offrono uno sguardo riassuntivo su quello che 351ci si aspetterà essere nel kernel principale nel successivo periodo 352d'incorporazione. 353Coloro che vorranno fare dei test d'esecuzione del kernel -next sono più che 354benvenuti. 355 356 357Riportare Bug 358------------- 359 360Il file 'Documentation/admin-guide/reporting-issues.rst' nella 361cartella principale del kernel spiega come segnalare un baco nel 362kernel, e fornisce dettagli su quali informazioni sono necessarie agli 363sviluppatori del kernel per poter studiare il problema. 364 365Gestire i rapporti sui bug 366-------------------------- 367 368Uno dei modi migliori per mettere in pratica le vostre capacità di hacking è 369quello di riparare bachi riportati da altre persone. Non solo aiuterete a far 370diventare il kernel più stabile, ma imparerete a riparare problemi veri dal 371mondo ed accrescerete le vostre competenze, e gli altri sviluppatori saranno 372al corrente della vostra presenza. Riparare bachi è una delle migliori vie per 373acquisire meriti tra gli altri sviluppatori, perchè non a molte persone piace 374perdere tempo a sistemare i bachi di altri. 375 376Per lavorare sui bachi già segnalati, per prima cosa cercate il 377sottosistema che vi interessa. Poi, verificate nel file MAINTAINERS 378dove vengono collezionati solitamente i bachi per quel sottosistema; 379spesso sarà una lista di discussione, raramente un bugtracker. Cercate 380bachi nell'archivio e aiutate dove credete di poterlo fare. Potete 381anche consultare https://bugzilla.kernel.org; però, solo una manciata di 382sottosistemi lo usano attivamente, ciò nonostante i bachi che 383coinvolgono l'intero kernel sono sempre riportati lì. 384 385Liste di discussione 386-------------------- 387 388Come descritto in molti dei documenti qui sopra, la maggior parte degli 389sviluppatori del kernel partecipano alla lista di discussione Linux Kernel. 390I dettagli su come iscriversi e disiscriversi dalla lista possono essere 391trovati al sito: 392 393 http://vger.kernel.org/vger-lists.html#linux-kernel 394 395Ci sono diversi archivi della lista di discussione. Usate un qualsiasi motore 396di ricerca per trovarli. Per esempio: 397 398 http://dir.gmane.org/gmane.linux.kernel 399 400É caldamente consigliata una ricerca in questi archivi sul tema che volete 401sollevare, prima di pubblicarlo sulla lista. Molte cose sono già state 402discusse in dettaglio e registrate negli archivi della lista di discussione. 403 404Molti dei sottosistemi del kernel hanno anche una loro lista di discussione 405dedicata. Guardate nel file MAINTAINERS per avere una lista delle liste di 406discussione e il loro uso. 407 408Molte di queste liste sono gestite su kernel.org. Per informazioni consultate 409la seguente pagina: 410 411 http://vger.kernel.org/vger-lists.html 412 413Per favore ricordatevi della buona educazione quando utilizzate queste liste. 414Sebbene sia un pò dozzinale, il seguente URL contiene alcune semplici linee 415guida per interagire con la lista (o con qualsiasi altra lista): 416 417 http://www.albion.com/netiquette/ 418 419Se diverse persone rispondo alla vostra mail, la lista dei riceventi (copia 420conoscenza) potrebbe diventare abbastanza lunga. Non cancellate nessuno dalla 421lista di CC: senza un buon motivo, e non rispondete solo all'indirizzo 422della lista di discussione. Fateci l'abitudine perché capita spesso di 423ricevere la stessa email due volte: una dal mittente ed una dalla lista; e non 424cercate di modificarla aggiungendo intestazioni stravaganti, agli altri non 425piacerà. 426 427Ricordate di rimanere sempre in argomento e di mantenere le attribuzioni 428delle vostre risposte invariate; mantenete il "John Kernelhacker wrote ...:" 429in cima alla vostra replica e aggiungete le vostre risposte fra i singoli 430blocchi citati, non scrivete all'inizio dell'email. 431 432Se aggiungete patch alla vostra mail, assicuratevi che siano del tutto 433leggibili come indicato in Documentation/process/submitting-patches.rst. 434Gli sviluppatori kernel non vogliono avere a che fare con allegati o patch 435compresse; vogliono invece poter commentare le righe dei vostri cambiamenti, 436il che può funzionare solo in questo modo. 437Assicuratevi di utilizzare un gestore di mail che non alterì gli spazi ed i 438caratteri. Un ottimo primo test è quello di inviare a voi stessi una mail e 439cercare di sottoporre la vostra stessa patch. Se non funziona, sistemate il 440vostro programma di posta, o cambiatelo, finché non funziona. 441 442Ed infine, per favore ricordatevi di mostrare rispetto per gli altri 443sottoscriventi. 444 445Lavorare con la comunità 446------------------------ 447 448L'obiettivo di questa comunità è quello di fornire il miglior kernel possibile. 449Quando inviate una modifica che volete integrare, sarà valutata esclusivamente 450dal punto di vista tecnico. Quindi, cosa dovreste aspettarvi? 451 452 - critiche 453 - commenti 454 - richieste di cambiamento 455 - richieste di spiegazioni 456 - nulla 457 458Ricordatevi che questo fa parte dell'integrazione della vostra modifica 459all'interno del kernel. Dovete essere in grado di accettare le critiche, 460valutarle a livello tecnico ed eventualmente rielaborare nuovamente le vostre 461modifiche o fornire delle chiare e concise motivazioni per le quali le 462modifiche suggerite non dovrebbero essere fatte. 463Se non riceverete risposte, aspettate qualche giorno e riprovate ancora, 464qualche volta le cose si perdono nell'enorme mucchio di email. 465 466Cosa non dovreste fare? 467 468 - aspettarvi che la vostra modifica venga accettata senza problemi 469 - mettervi sulla difensiva 470 - ignorare i commenti 471 - sottomettere nuovamente la modifica senza fare nessuno dei cambiamenti 472 richiesti 473 474In una comunità che è alla ricerca delle migliori soluzioni tecniche possibili, 475ci saranno sempre opinioni differenti sull'utilità di una modifica. 476Siate cooperativi e vogliate adattare la vostra idea in modo che sia inserita 477nel kernel. O almeno vogliate dimostrare che la vostra idea vale. 478Ricordatevi, sbagliare è accettato fintanto che siate disposti a lavorare verso 479una soluzione che è corretta. 480 481È normale che le risposte alla vostra prima modifica possa essere 482semplicemente una lista con dozzine di cose che dovreste correggere. 483Questo **non** implica che la vostra patch non sarà accettata, e questo 484**non** è contro di voi personalmente. 485Semplicemente correggete tutte le questioni sollevate contro la vostra modifica 486ed inviatela nuovamente. 487 488Differenze tra la comunità del kernel e le strutture aziendali 489-------------------------------------------------------------- 490 491La comunità del kernel funziona diversamente rispetto a molti ambienti di 492sviluppo aziendali. Qui di seguito una lista di cose che potete provare a 493fare per evitare problemi: 494 495 Cose da dire riguardanti le modifiche da voi proposte: 496 497 - "Questo risolve più problematiche." 498 - "Questo elimina 2000 stringhe di codice." 499 - "Qui una modifica che spiega cosa sto cercando di fare." 500 - "L'ho testato su 5 diverse architetture.." 501 - "Qui una serie di piccole modifiche che.." 502 - "Questo aumenta le prestazioni di macchine standard..." 503 504 Cose che dovreste evitare di dire: 505 506 - "Lo abbiamo fatto in questo modo in AIX/ptx/Solaris, di conseguenza 507 deve per forza essere giusto..." 508 - "Ho fatto questo per 20 anni, quindi.." 509 - "Questo è richiesto dalla mia Azienda per far soldi" 510 - "Questo è per la linea di prodotti della nostra Azienda" 511 - "Ecco il mio documento di design di 1000 pagine che descrive ciò che ho 512 in mente" 513 - "Ci ho lavorato per 6 mesi..." 514 - "Ecco una patch da 5000 righe che.." 515 - "Ho riscritto il pasticcio attuale, ed ecco qua.." 516 - "Ho una scadenza, e questa modifica ha bisogno di essere approvata ora" 517 518Un'altra cosa nella quale la comunità del kernel si differenzia dai più 519classici ambienti di ingegneria del software è la natura "senza volto" delle 520interazioni umane. Uno dei benefici dell'uso delle email e di irc come forma 521primordiale di comunicazione è l'assenza di discriminazione basata su genere e 522razza. L'ambienti di lavoro Linux accetta donne e minoranze perchè tutto quello 523che sei è un indirizzo email. Aiuta anche l'aspetto internazionale nel 524livellare il terreno di gioco perchè non è possibile indovinare il genere 525basandosi sul nome di una persona. Un uomo può chiamarsi Andrea ed una donna 526potrebbe chiamarsi Pat. Gran parte delle donne che hanno lavorato al kernel 527Linux e che hanno espresso una personale opinione hanno avuto esperienze 528positive. 529 530La lingua potrebbe essere un ostacolo per quelle persone che non si trovano 531a loro agio con l'inglese. Una buona padronanza del linguaggio può essere 532necessaria per esporre le proprie idee in maniera appropiata all'interno 533delle liste di discussione, quindi è consigliabile che rileggiate le vostre 534email prima di inviarle in modo da essere certi che abbiano senso in inglese. 535 536 537Spezzare le vostre modifiche 538---------------------------- 539 540La comunità del kernel Linux non accetta con piacere grossi pezzi di codice 541buttati lì tutti in una volta. Le modifiche necessitano di essere 542adeguatamente presentate, discusse, e suddivise in parti più piccole ed 543indipendenti. Questo è praticamente l'esatto opposto di quello che le 544aziende fanno solitamente. La vostra proposta dovrebbe, inoltre, essere 545presentata prestissimo nel processo di sviluppo, così che possiate ricevere 546un riscontro su quello che state facendo. Lasciate che la comunità 547senta che state lavorando con loro, e che non li stiate sfruttando come 548discarica per le vostre aggiunte. In ogni caso, non inviate 50 email nello 549stesso momento in una lista di discussione, il più delle volte la vostra serie 550di modifiche dovrebbe essere più piccola. 551 552I motivi per i quali dovreste frammentare le cose sono i seguenti: 553 5541) Piccole modifiche aumentano le probabilità che vengano accettate, 555 altrimenti richiederebbe troppo tempo o sforzo nel verificarne 556 la correttezza. Una modifica di 5 righe può essere accettata da un 557 manutentore con a mala pena una seconda occhiata. Invece, una modifica da 558 500 linee può richiedere ore di rilettura per verificarne la correttezza 559 (il tempo necessario è esponenzialmente proporzionale alla dimensione della 560 modifica, o giù di lì) 561 562 Piccole modifiche sono inoltre molto facili da debuggare quando qualcosa 563 non va. È molto più facile annullare le modifiche una per una che 564 dissezionare una patch molto grande dopo la sua sottomissione (e rompere 565 qualcosa). 566 5672) È importante non solo inviare piccole modifiche, ma anche riscriverle e 568 semplificarle (o più semplicemente ordinarle) prima di sottoporle. 569 570Qui un'analogia dello sviluppatore kernel Al Viro: 571 572 *"Pensate ad un insegnante di matematica che corregge il compito 573 di uno studente (di matematica). L'insegnante non vuole vedere le 574 prove e gli errori commessi dallo studente prima che arrivi alla 575 soluzione. Vuole vedere la risposta più pulita ed elegante 576 possibile. Un buono studente lo sa, e non presenterebbe mai le 577 proprie bozze prima prima della soluzione finale"* 578 579 *"Lo stesso vale per lo sviluppo del kernel. I manutentori ed i 580 revisori non vogliono vedere il procedimento che sta dietro al 581 problema che uno sta risolvendo. Vogliono vedere una soluzione 582 semplice ed elegante."* 583 584Può essere una vera sfida il saper mantenere l'equilibrio fra una presentazione 585elegante della vostra soluzione, lavorare insieme ad una comunità e dibattere 586su un lavoro incompleto. Pertanto è bene entrare presto nel processo di 587revisione per migliorare il vostro lavoro, ma anche per riuscire a tenere le 588vostre modifiche in pezzettini che potrebbero essere già accettate, nonostante 589la vostra intera attività non lo sia ancora. 590 591In fine, rendetevi conto che non è accettabile inviare delle modifiche 592incomplete con la promessa che saranno "sistemate dopo". 593 594 595Giustificare le vostre modifiche 596-------------------------------- 597 598Insieme alla frammentazione delle vostre modifiche, è altrettanto importante 599permettere alla comunità Linux di capire perché dovrebbero accettarle. 600Nuove funzionalità devono essere motivate come necessarie ed utili. 601 602 603Documentare le vostre modifiche 604------------------------------- 605 606Quando inviate le vostre modifiche, fate particolare attenzione a quello che 607scrivete nella vostra email. Questa diventerà il *ChangeLog* per la modifica, 608e sarà visibile a tutti per sempre. Dovrebbe descrivere la modifica nella sua 609interezza, contenendo: 610 611 - perchè la modifica è necessaria 612 - l'approccio d'insieme alla patch 613 - dettagli supplementari 614 - risultati dei test 615 616Per maggiori dettagli su come tutto ciò dovrebbe apparire, riferitevi alla 617sezione ChangeLog del documento: 618 619 "The Perfect Patch" 620 http://www.ozlabs.org/~akpm/stuff/tpp.txt 621 622A volte tutto questo è difficile da realizzare. Il perfezionamento di queste 623pratiche può richiedere anni (eventualmente). È un processo continuo di 624miglioramento che richiede molta pazienza e determinazione. Ma non mollate, 625si può fare. Molti lo hanno fatto prima, ed ognuno ha dovuto iniziare dove 626siete voi ora. 627 628 629 630 631---------- 632 633Grazie a Paolo Ciarrocchi che ha permesso che la sezione "Development Process" 634(https://lwn.net/Articles/94386/) fosse basata sui testi da lui scritti, ed a 635Randy Dunlap e Gerrit Huizenga per la lista di cose che dovreste e non 636dovreste dire. Grazie anche a Pat Mochel, Hanna Linder, Randy Dunlap, 637Kay Sievers, Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook, Andrew Morton, 638Andi Kleen, Vadim Lobanov, Jesper Juhl, Adrian Bunk, Keri Harris, Frans Pop, 639David A. Wheeler, Junio Hamano, Michael Kerrisk, e Alex Shepard per le 640loro revisioni, commenti e contributi. Senza il loro aiuto, questo documento 641non sarebbe stato possibile. 642 643Manutentore: Greg Kroah-Hartman <greg@kroah.com>