0001 .. include:: ../disclaimer-ita.rst
0002
0003 :Original: :ref:`Documentation/process/howto.rst <process_howto>`
0004 :Translator: Alessia Mantegazza <amantegazza@vaga.pv.it>
0005
0006 .. _it_process_howto:
0007
0008 Come partecipare allo sviluppo del kernel Linux
0009 ===============================================
0010
0011 Questo è il documento fulcro di quanto trattato sull'argomento.
0012 Esso contiene le istruzioni su come diventare uno sviluppatore
0013 del kernel Linux e spiega come lavorare con la comunità di
0014 sviluppo kernel Linux. Il documento non tratterà alcun aspetto
0015 tecnico relativo alla programmazione del kernel, ma vi aiuterà
0016 indirizzandovi sulla corretta strada.
0017
0018 Se qualsiasi cosa presente in questo documento diventasse obsoleta,
0019 vi preghiamo di inviare le correzioni agli amministratori di questo
0020 file, indicati in fondo al presente documento.
0021
0022 Introduzione
0023 ------------
0024 Dunque, volete imparare come diventare sviluppatori del kernel Linux?
0025 O vi è stato detto dal vostro capo, "Vai, scrivi un driver Linux per
0026 questo dispositivo". Bene, l'obbiettivo di questo documento è quello
0027 di insegnarvi tutto ciò che dovete sapere per raggiungere il vostro
0028 scopo descrivendo il procedimento da seguire e consigliandovi
0029 su come lavorare con la comunità. Il documento cercherà, inoltre,
0030 di spiegare alcune delle ragioni per le quali la comunità lavora in un
0031 modo suo particolare.
0032
0033 Il kernel è scritto prevalentemente nel linguaggio C con alcune parti
0034 specifiche dell'architettura scritte in linguaggio assembly.
0035 Per lo sviluppo kernel è richiesta una buona conoscenza del linguaggio C.
0036 L'assembly (di qualsiasi architettura) non è richiesto, a meno che non
0037 pensiate di fare dello sviluppo di basso livello per un'architettura.
0038 Sebbene essi non siano un buon sostituto ad un solido studio del
0039 linguaggio C o ad anni di esperienza, i seguenti libri sono, se non
0040 altro, utili riferimenti:
0041
0042 - "The C Programming Language" di Kernighan e Ritchie [Prentice Hall]
0043 - "Practical C Programming" di Steve Oualline [O'Reilly]
0044 - "C: A Reference Manual" di Harbison and Steele [Prentice Hall]
0045
0046 Il kernel è stato scritto usando GNU C e la toolchain GNU.
0047 Sebbene si attenga allo standard ISO C89, esso utilizza una serie di
0048 estensioni che non sono previste in questo standard. Il kernel è un
0049 ambiente C indipendente, che non ha alcuna dipendenza dalle librerie
0050 C standard, così alcune parti del C standard non sono supportate.
0051 Le divisioni ``long long`` e numeri in virgola mobile non sono permessi.
0052 Qualche volta è difficile comprendere gli assunti che il kernel ha
0053 riguardo gli strumenti e le estensioni in uso, e sfortunatamente non
0054 esiste alcuna indicazione definitiva. Per maggiori informazioni, controllate,
0055 la pagina `info gcc`.
0056
0057 Tenete a mente che state cercando di apprendere come lavorare con la comunità
0058 di sviluppo già esistente. Questo è un gruppo eterogeneo di persone, con alti
0059 standard di codifica, di stile e di procedura. Questi standard sono stati
0060 creati nel corso del tempo basandosi su quanto hanno riscontrato funzionare al
0061 meglio per un squadra così grande e geograficamente sparsa. Cercate di
0062 imparare, in anticipo, il più possibile circa questi standard, poichè ben
0063 spiegati; non aspettatevi che gli altri si adattino al vostro modo di fare
0064 o a quello della vostra azienda.
0065
0066 Note legali
0067 ------------
0068 Il codice sorgente del kernel Linux è rilasciato sotto GPL. Siete pregati
0069 di visionare il file, COPYING, presente nella cartella principale dei
0070 sorgente, per eventuali dettagli sulla licenza. Se avete ulteriori domande
0071 sulla licenza, contattate un avvocato, non chiedete sulle liste di discussione
0072 del kernel Linux. Le persone presenti in queste liste non sono avvocati,
0073 e non dovreste basarvi sulle loro dichiarazioni in materia giuridica.
0074
0075 Per domande più frequenti e risposte sulla licenza GPL, guardare:
0076
0077 https://www.gnu.org/licenses/gpl-faq.html
0078
0079 Documentazione
0080 --------------
0081 I sorgenti del kernel Linux hanno una vasta base di documenti che vi
0082 insegneranno come interagire con la comunità del kernel. Quando nuove
0083 funzionalità vengono aggiunte al kernel, si raccomanda di aggiungere anche i
0084 relativi file di documentatione che spiegano come usarele.
0085 Quando un cambiamento del kernel genera anche un cambiamento nell'interfaccia
0086 con lo spazio utente, è raccomandabile che inviate una notifica o una
0087 correzione alle pagine *man* spiegando tale modifica agli amministratori di
0088 queste pagine all'indirizzo mtk.manpages@gmail.com, aggiungendo
0089 in CC la lista linux-api@vger.kernel.org.
0090
0091 Di seguito una lista di file che sono presenti nei sorgente del kernel e che
0092 è richiesto che voi leggiate:
0093
0094 :ref:`Documentation/translations/it_IT/admin-guide/README.rst <it_readme>`
0095 Questo file da una piccola anteprima del kernel Linux e descrive il
0096 minimo necessario per configurare e generare il kernel. I novizi
0097 del kernel dovrebbero iniziare da qui.
0098
0099 :ref:`Documentation/translations/it_IT/process/changes.rst <it_changes>`
0100
0101 Questo file fornisce una lista dei pacchetti software necessari
0102 a compilare e far funzionare il kernel con successo.
0103
0104 :ref:`Documentation/translations/it_IT/process/coding-style.rst <it_codingstyle>`
0105
0106 Questo file descrive lo stile della codifica per il kernel Linux,
0107 e parte delle motivazioni che ne sono alla base. Tutto il nuovo codice deve
0108 seguire le linee guida in questo documento. Molti amministratori
0109 accetteranno patch solo se queste osserveranno tali regole, e molte
0110 persone revisioneranno il codice solo se scritto nello stile appropriato.
0111
0112 :ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`
0113
0114 Questo file descrive dettagliatamente come creare ed inviare una patch
0115 con successo, includendo (ma non solo questo):
0116
0117 - Contenuto delle email
0118 - Formato delle email
0119 - I destinatari delle email
0120
0121 Seguire tali regole non garantirà il successo (tutte le patch sono soggette
0122 a controlli realitivi a contenuto e stile), ma non seguirle lo precluderà
0123 sempre.
0124
0125 Altre ottime descrizioni di come creare buone patch sono:
0126
0127 "The Perfect Patch"
0128 https://www.ozlabs.org/~akpm/stuff/tpp.txt
0129
0130 "Linux kernel patch submission format"
0131 https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html
0132
0133 :ref:`Documentation/translations/it_IT/process/stable-api-nonsense.rst <it_stable_api_nonsense>`
0134
0135 Questo file descrive la motivazioni sottostanti la conscia decisione di
0136 non avere un API stabile all'interno del kernel, incluso cose come:
0137
0138 - Sottosistemi shim-layers (per compatibilità?)
0139 - Portabilità fra Sistemi Operativi dei driver.
0140 - Attenuare i rapidi cambiamenti all'interno dei sorgenti del kernel
0141 (o prevenirli)
0142
0143 Questo documento è vitale per la comprensione della filosifia alla base
0144 dello sviluppo di Linux ed è molto importante per le persone che arrivano
0145 da esperienze con altri Sistemi Operativi.
0146
0147 :ref:`Documentation/translations/it_IT/admin-guide/security-bugs.rst <it_securitybugs>`
0148 Se ritenete di aver trovato un problema di sicurezza nel kernel Linux,
0149 seguite i passaggi scritti in questo documento per notificarlo agli
0150 sviluppatori del kernel, ed aiutare la risoluzione del problema.
0151
0152 :ref:`Documentation/translations/it_IT/process/management-style.rst <it_managementstyle>`
0153 Questo documento descrive come i manutentori del kernel Linux operano
0154 e la filosofia comune alla base del loro metodo. Questa è un'importante
0155 lettura per tutti coloro che sono nuovi allo sviluppo del kernel (o per
0156 chi è semplicemente curioso), poiché risolve molti dei più comuni
0157 fraintendimenti e confusioni dovuti al particolare comportamento dei
0158 manutentori del kernel.
0159
0160 :ref:`Documentation/translations/it_IT/process/stable-kernel-rules.rst <it_stable_kernel_rules>`
0161 Questo file descrive le regole sulle quali vengono basati i rilasci del
0162 kernel, e spiega cosa fare se si vuole che una modifica venga inserita
0163 in uno di questi rilasci.
0164
0165 :ref:`Documentation/translations/it_IT/process/kernel-docs.rst <it_kernel_docs>`
0166 Una lista di documenti pertinenti allo sviluppo del kernel.
0167 Per favore consultate questa lista se non trovate ciò che cercate nella
0168 documentazione interna del kernel.
0169
0170 :ref:`Documentation/translations/it_IT/process/applying-patches.rst <it_applying_patches>`
0171 Una buona introduzione che descrivere esattamente cos'è una patch e come
0172 applicarla ai differenti rami di sviluppo del kernel.
0173
0174 Il kernel inoltre ha un vasto numero di documenti che possono essere
0175 automaticamente generati dal codice sorgente stesso o da file
0176 ReStructuredText (ReST), come questo. Esso include una completa
0177 descrizione dell'API interna del kernel, e le regole su come gestire la
0178 sincronizzazione (locking) correttamente
0179
0180 Tutte queste tipologie di documenti possono essere generati in PDF o in
0181 HTML utilizzando::
0182
0183 make pdfdocs
0184 make htmldocs
0185
0186 rispettivamente dalla cartella principale dei sorgenti del kernel.
0187
0188 I documenti che impiegano ReST saranno generati nella cartella
0189 Documentation/output.
0190 Questi posso essere generati anche in formato LaTex e ePub con::
0191
0192 make latexdocs
0193 make epubdocs
0194
0195 Diventare uno sviluppatore del kernel
0196 -------------------------------------
0197 Se non sapete nulla sullo sviluppo del kernel Linux, dovreste dare uno
0198 sguardo al progetto *Linux KernelNewbies*:
0199
0200 https://kernelnewbies.org
0201
0202 Esso prevede un'utile lista di discussione dove potete porre più o meno ogni
0203 tipo di quesito relativo ai concetti fondamentali sullo sviluppo del kernel
0204 (assicuratevi di cercare negli archivi, prima di chiedere qualcosa alla
0205 quale è già stata fornita risposta in passato). Esistono inoltre, un canale IRC
0206 che potete usare per formulare domande in tempo reale, e molti documenti utili
0207 che vi faciliteranno nell'apprendimento dello sviluppo del kernel Linux.
0208
0209 Il sito internet contiene informazioni di base circa l'organizzazione del
0210 codice, sottosistemi e progetti attuali (sia interni che esterni a Linux).
0211 Esso descrive, inoltre, informazioni logistiche di base, riguardanti ad esempio
0212 la compilazione del kernel e l'applicazione di una modifica.
0213
0214 Se non sapete dove cominciare, ma volete cercare delle attività dalle quali
0215 partire per partecipare alla comunità di sviluppo, andate al progetto Linux
0216 Kernel Janitor's.
0217
0218 https://kernelnewbies.org/KernelJanitors
0219
0220 È un buon posto da cui iniziare. Esso presenta una lista di problematiche
0221 relativamente semplici da sistemare e pulire all'interno della sorgente del
0222 kernel Linux. Lavorando con gli sviluppatori incaricati di questo progetto,
0223 imparerete le basi per l'inserimento delle vostre modifiche all'interno dei
0224 sorgenti del kernel Linux, e possibilmente, sarete indirizzati al lavoro
0225 successivo da svolgere, se non ne avrete ancora idea.
0226
0227 Prima di apportare una qualsiasi modifica al codice del kernel Linux,
0228 è imperativo comprendere come tale codice funziona. A questo scopo, non c'è
0229 nulla di meglio che leggerlo direttamente (la maggior parte dei bit più
0230 complessi sono ben commentati), eventualmente anche con l'aiuto di strumenti
0231 specializzati. Uno degli strumenti che è particolarmente raccomandato è
0232 il progetto Linux Cross-Reference, che è in grado di presentare codice
0233 sorgente in un formato autoreferenziale ed indicizzato. Un eccellente ed
0234 aggiornata fonte di consultazione del codice del kernel la potete trovare qui:
0235
0236 https://elixir.bootlin.com/
0237
0238
0239 Il processo di sviluppo
0240 -----------------------
0241 Il processo di sviluppo del kernel Linux si compone di pochi "rami" principali
0242 e di molti altri rami per specifici sottosistemi. Questi rami sono:
0243
0244 - I sorgenti kernel 4.x
0245 - I sorgenti stabili del kernel 4.x.y -stable
0246 - Sorgenti dei sottosistemi del kernel e le loro modifiche
0247 - Il kernel 4.x -next per test d'integrazione
0248
0249 I sorgenti kernel 4.x
0250 ~~~~~~~~~~~~~~~~~~~~~
0251
0252 I kernel 4.x sono amministrati da Linus Torvald, e possono essere trovati
0253 su https://kernel.org nella cartella pub/linux/kernel/v4.x/. Il processo
0254 di sviluppo è il seguente:
0255
0256 - Non appena un nuovo kernel viene rilasciato si apre una finestra di due
0257 settimane. Durante questo periodo i manutentori possono proporre a Linus
0258 dei grossi cambiamenti; solitamente i cambiamenti che sono già stati
0259 inseriti nel ramo -next del kernel per alcune settimane. Il modo migliore
0260 per sottoporre dei cambiamenti è attraverso git (lo strumento usato per
0261 gestire i sorgenti del kernel, più informazioni sul sito
0262 https://git-scm.com/) ma anche delle patch vanno bene.
0263
0264 - Al termine delle due settimane un kernel -rc1 viene rilasciato e
0265 l'obbiettivo ora è quello di renderlo il più solido possibile. A questo
0266 punto la maggior parte delle patch dovrebbero correggere un'eventuale
0267 regressione. I bachi che sono sempre esistiti non sono considerabili come
0268 regressioni, quindi inviate questo tipo di cambiamenti solo se sono
0269 importanti. Notate che un intero driver (o filesystem) potrebbe essere
0270 accettato dopo la -rc1 poiché non esistono rischi di una possibile
0271 regressione con tale cambiamento, fintanto che quest'ultimo è
0272 auto-contenuto e non influisce su aree esterne al codice che è stato
0273 aggiunto. git può essere utilizzato per inviare le patch a Linus dopo che
0274 la -rc1 è stata rilasciata, ma è anche necessario inviare le patch ad
0275 una lista di discussione pubblica per un'ulteriore revisione.
0276
0277 - Una nuova -rc viene rilasciata ogni volta che Linus reputa che gli attuali
0278 sorgenti siano in uno stato di salute ragionevolmente adeguato ai test.
0279 L'obiettivo è quello di rilasciare una nuova -rc ogni settimana.
0280
0281 - Il processo continua fino a che il kernel è considerato "pronto"; tale
0282 processo dovrebbe durare circa in 6 settimane.
0283
0284 È utile menzionare quanto scritto da Andrew Morton sulla lista di discussione
0285 kernel-linux in merito ai rilasci del kernel:
0286
0287 *"Nessuno sa quando un kernel verrà rilasciato, poichè questo è
0288 legato allo stato dei bachi e non ad una cronologia preventiva."*
0289
0290 I sorgenti stabili del kernel 4.x.y -stable
0291 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0292
0293 I kernel con versioni in 3-parti sono "kernel stabili". Essi contengono
0294 correzioni critiche relativamente piccole nell'ambito della sicurezza
0295 oppure significative regressioni scoperte in un dato 4.x kernel.
0296
0297 Questo è il ramo raccomandato per gli utenti che vogliono un kernel recente
0298 e stabile e non sono interessati a dare il proprio contributo alla verifica
0299 delle versioni di sviluppo o sperimentali.
0300
0301 Se non è disponibile alcun kernel 4.x.y., quello più aggiornato e stabile
0302 sarà il kernel 4.x con la numerazione più alta.
0303
0304 4.x.y sono amministrati dal gruppo "stable" <stable@vger.kernel.org>, e sono
0305 rilasciati a seconda delle esigenze. Il normale periodo di rilascio è
0306 approssimativamente di due settimane, ma può essere più lungo se non si
0307 verificano problematiche urgenti. Un problema relativo alla sicurezza, invece,
0308 può determinare un rilascio immediato.
0309
0310 Il file Documentation/process/stable-kernel-rules.rst (nei sorgenti) documenta
0311 quali tipologie di modifiche sono accettate per i sorgenti -stable, e come
0312 avviene il processo di rilascio.
0313
0314
0315 Sorgenti dei sottosistemi del kernel e le loro patch
0316 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0317
0318 I manutentori dei diversi sottosistemi del kernel --- ed anche molti
0319 sviluppatori di sottosistemi --- mostrano il loro attuale stato di sviluppo
0320 nei loro repositori. In questo modo, altri possono vedere cosa succede nelle
0321 diverse parti del kernel. In aree dove lo sviluppo è rapido, potrebbe essere
0322 chiesto ad uno sviluppatore di basare le proprie modifiche su questi repositori
0323 in modo da evitare i conflitti fra le sottomissioni ed altri lavori in corso
0324
0325 La maggior parte di questi repositori sono git, ma esistono anche altri SCM
0326 in uso, o file di patch pubblicate come una serie quilt.
0327 Gli indirizzi dei repositori di sottosistema sono indicati nel file
0328 MAINTAINERS. Molti di questi posso essere trovati su https://git.kernel.org/.
0329
0330 Prima che una modifica venga inclusa in questi sottosistemi, sarà soggetta ad
0331 una revisione che inizialmente avviene tramite liste di discussione (vedere la
0332 sezione dedicata qui sotto). Per molti sottosistemi del kernel, tale processo
0333 di revisione è monitorato con lo strumento patchwork.
0334 Patchwork offre un'interfaccia web che mostra le patch pubblicate, inclusi i
0335 commenti o le revisioni fatte, e gli amministratori possono indicare le patch
0336 come "in revisione", "accettate", o "rifiutate". Diversi siti Patchwork sono
0337 elencati al sito https://patchwork.kernel.org/.
0338
0339 Il kernel 4.x -next per test d'integrazione
0340 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0341
0342 Prima che gli aggiornamenti dei sottosistemi siano accorpati nel ramo
0343 principale 4.x, sarà necessario un test d'integrazione.
0344 A tale scopo, esiste un repositorio speciale di test nel quale virtualmente
0345 tutti i rami dei sottosistemi vengono inclusi su base quotidiana:
0346
0347 https://git.kernel.org/?p=linux/kernel/git/next/linux-next.git
0348
0349 In questo modo, i kernel -next offrono uno sguardo riassuntivo su quello che
0350 ci si aspetterà essere nel kernel principale nel successivo periodo
0351 d'incorporazione.
0352 Coloro che vorranno fare dei test d'esecuzione del kernel -next sono più che
0353 benvenuti.
0354
0355
0356 Riportare Bug
0357 -------------
0358
0359 Il file 'Documentation/admin-guide/reporting-issues.rst' nella
0360 cartella principale del kernel spiega come segnalare un baco nel
0361 kernel, e fornisce dettagli su quali informazioni sono necessarie agli
0362 sviluppatori del kernel per poter studiare il problema.
0363
0364 Gestire i rapporti sui bug
0365 --------------------------
0366
0367 Uno dei modi migliori per mettere in pratica le vostre capacità di hacking è
0368 quello di riparare bachi riportati da altre persone. Non solo aiuterete a far
0369 diventare il kernel più stabile, ma imparerete a riparare problemi veri dal
0370 mondo ed accrescerete le vostre competenze, e gli altri sviluppatori saranno
0371 al corrente della vostra presenza. Riparare bachi è una delle migliori vie per
0372 acquisire meriti tra gli altri sviluppatori, perchè non a molte persone piace
0373 perdere tempo a sistemare i bachi di altri.
0374
0375 Per lavorare sui bachi già segnalati, per prima cosa cercate il
0376 sottosistema che vi interessa. Poi, verificate nel file MAINTAINERS
0377 dove vengono collezionati solitamente i bachi per quel sottosistema;
0378 spesso sarà una lista di discussione, raramente un bugtracker. Cercate
0379 bachi nell'archivio e aiutate dove credete di poterlo fare. Potete
0380 anche consultare https://bugzilla.kernel.org; però, solo una manciata di
0381 sottosistemi lo usano attivamente, ciò nonostante i bachi che
0382 coinvolgono l'intero kernel sono sempre riportati lì.
0383
0384 Liste di discussione
0385 --------------------
0386
0387 Come descritto in molti dei documenti qui sopra, la maggior parte degli
0388 sviluppatori del kernel partecipano alla lista di discussione Linux Kernel.
0389 I dettagli su come iscriversi e disiscriversi dalla lista possono essere
0390 trovati al sito:
0391
0392 http://vger.kernel.org/vger-lists.html#linux-kernel
0393
0394 Ci sono diversi archivi della lista di discussione. Usate un qualsiasi motore
0395 di ricerca per trovarli. Per esempio:
0396
0397 http://dir.gmane.org/gmane.linux.kernel
0398
0399 É caldamente consigliata una ricerca in questi archivi sul tema che volete
0400 sollevare, prima di pubblicarlo sulla lista. Molte cose sono già state
0401 discusse in dettaglio e registrate negli archivi della lista di discussione.
0402
0403 Molti dei sottosistemi del kernel hanno anche una loro lista di discussione
0404 dedicata. Guardate nel file MAINTAINERS per avere una lista delle liste di
0405 discussione e il loro uso.
0406
0407 Molte di queste liste sono gestite su kernel.org. Per informazioni consultate
0408 la seguente pagina:
0409
0410 http://vger.kernel.org/vger-lists.html
0411
0412 Per favore ricordatevi della buona educazione quando utilizzate queste liste.
0413 Sebbene sia un pò dozzinale, il seguente URL contiene alcune semplici linee
0414 guida per interagire con la lista (o con qualsiasi altra lista):
0415
0416 http://www.albion.com/netiquette/
0417
0418 Se diverse persone rispondo alla vostra mail, la lista dei riceventi (copia
0419 conoscenza) potrebbe diventare abbastanza lunga. Non cancellate nessuno dalla
0420 lista di CC: senza un buon motivo, e non rispondete solo all'indirizzo
0421 della lista di discussione. Fateci l'abitudine perché capita spesso di
0422 ricevere la stessa email due volte: una dal mittente ed una dalla lista; e non
0423 cercate di modificarla aggiungendo intestazioni stravaganti, agli altri non
0424 piacerà.
0425
0426 Ricordate di rimanere sempre in argomento e di mantenere le attribuzioni
0427 delle vostre risposte invariate; mantenete il "John Kernelhacker wrote ...:"
0428 in cima alla vostra replica e aggiungete le vostre risposte fra i singoli
0429 blocchi citati, non scrivete all'inizio dell'email.
0430
0431 Se aggiungete patch alla vostra mail, assicuratevi che siano del tutto
0432 leggibili come indicato in Documentation/process/submitting-patches.rst.
0433 Gli sviluppatori kernel non vogliono avere a che fare con allegati o patch
0434 compresse; vogliono invece poter commentare le righe dei vostri cambiamenti,
0435 il che può funzionare solo in questo modo.
0436 Assicuratevi di utilizzare un gestore di mail che non alterì gli spazi ed i
0437 caratteri. Un ottimo primo test è quello di inviare a voi stessi una mail e
0438 cercare di sottoporre la vostra stessa patch. Se non funziona, sistemate il
0439 vostro programma di posta, o cambiatelo, finché non funziona.
0440
0441 Ed infine, per favore ricordatevi di mostrare rispetto per gli altri
0442 sottoscriventi.
0443
0444 Lavorare con la comunità
0445 ------------------------
0446
0447 L'obiettivo di questa comunità è quello di fornire il miglior kernel possibile.
0448 Quando inviate una modifica che volete integrare, sarà valutata esclusivamente
0449 dal punto di vista tecnico. Quindi, cosa dovreste aspettarvi?
0450
0451 - critiche
0452 - commenti
0453 - richieste di cambiamento
0454 - richieste di spiegazioni
0455 - nulla
0456
0457 Ricordatevi che questo fa parte dell'integrazione della vostra modifica
0458 all'interno del kernel. Dovete essere in grado di accettare le critiche,
0459 valutarle a livello tecnico ed eventualmente rielaborare nuovamente le vostre
0460 modifiche o fornire delle chiare e concise motivazioni per le quali le
0461 modifiche suggerite non dovrebbero essere fatte.
0462 Se non riceverete risposte, aspettate qualche giorno e riprovate ancora,
0463 qualche volta le cose si perdono nell'enorme mucchio di email.
0464
0465 Cosa non dovreste fare?
0466
0467 - aspettarvi che la vostra modifica venga accettata senza problemi
0468 - mettervi sulla difensiva
0469 - ignorare i commenti
0470 - sottomettere nuovamente la modifica senza fare nessuno dei cambiamenti
0471 richiesti
0472
0473 In una comunità che è alla ricerca delle migliori soluzioni tecniche possibili,
0474 ci saranno sempre opinioni differenti sull'utilità di una modifica.
0475 Siate cooperativi e vogliate adattare la vostra idea in modo che sia inserita
0476 nel kernel. O almeno vogliate dimostrare che la vostra idea vale.
0477 Ricordatevi, sbagliare è accettato fintanto che siate disposti a lavorare verso
0478 una soluzione che è corretta.
0479
0480 È normale che le risposte alla vostra prima modifica possa essere
0481 semplicemente una lista con dozzine di cose che dovreste correggere.
0482 Questo **non** implica che la vostra patch non sarà accettata, e questo
0483 **non** è contro di voi personalmente.
0484 Semplicemente correggete tutte le questioni sollevate contro la vostra modifica
0485 ed inviatela nuovamente.
0486
0487 Differenze tra la comunità del kernel e le strutture aziendali
0488 --------------------------------------------------------------
0489
0490 La comunità del kernel funziona diversamente rispetto a molti ambienti di
0491 sviluppo aziendali. Qui di seguito una lista di cose che potete provare a
0492 fare per evitare problemi:
0493
0494 Cose da dire riguardanti le modifiche da voi proposte:
0495
0496 - "Questo risolve più problematiche."
0497 - "Questo elimina 2000 stringhe di codice."
0498 - "Qui una modifica che spiega cosa sto cercando di fare."
0499 - "L'ho testato su 5 diverse architetture.."
0500 - "Qui una serie di piccole modifiche che.."
0501 - "Questo aumenta le prestazioni di macchine standard..."
0502
0503 Cose che dovreste evitare di dire:
0504
0505 - "Lo abbiamo fatto in questo modo in AIX/ptx/Solaris, di conseguenza
0506 deve per forza essere giusto..."
0507 - "Ho fatto questo per 20 anni, quindi.."
0508 - "Questo è richiesto dalla mia Azienda per far soldi"
0509 - "Questo è per la linea di prodotti della nostra Azienda"
0510 - "Ecco il mio documento di design di 1000 pagine che descrive ciò che ho
0511 in mente"
0512 - "Ci ho lavorato per 6 mesi..."
0513 - "Ecco una patch da 5000 righe che.."
0514 - "Ho riscritto il pasticcio attuale, ed ecco qua.."
0515 - "Ho una scadenza, e questa modifica ha bisogno di essere approvata ora"
0516
0517 Un'altra cosa nella quale la comunità del kernel si differenzia dai più
0518 classici ambienti di ingegneria del software è la natura "senza volto" delle
0519 interazioni umane. Uno dei benefici dell'uso delle email e di irc come forma
0520 primordiale di comunicazione è l'assenza di discriminazione basata su genere e
0521 razza. L'ambienti di lavoro Linux accetta donne e minoranze perchè tutto quello
0522 che sei è un indirizzo email. Aiuta anche l'aspetto internazionale nel
0523 livellare il terreno di gioco perchè non è possibile indovinare il genere
0524 basandosi sul nome di una persona. Un uomo può chiamarsi Andrea ed una donna
0525 potrebbe chiamarsi Pat. Gran parte delle donne che hanno lavorato al kernel
0526 Linux e che hanno espresso una personale opinione hanno avuto esperienze
0527 positive.
0528
0529 La lingua potrebbe essere un ostacolo per quelle persone che non si trovano
0530 a loro agio con l'inglese. Una buona padronanza del linguaggio può essere
0531 necessaria per esporre le proprie idee in maniera appropiata all'interno
0532 delle liste di discussione, quindi è consigliabile che rileggiate le vostre
0533 email prima di inviarle in modo da essere certi che abbiano senso in inglese.
0534
0535
0536 Spezzare le vostre modifiche
0537 ----------------------------
0538
0539 La comunità del kernel Linux non accetta con piacere grossi pezzi di codice
0540 buttati lì tutti in una volta. Le modifiche necessitano di essere
0541 adeguatamente presentate, discusse, e suddivise in parti più piccole ed
0542 indipendenti. Questo è praticamente l'esatto opposto di quello che le
0543 aziende fanno solitamente. La vostra proposta dovrebbe, inoltre, essere
0544 presentata prestissimo nel processo di sviluppo, così che possiate ricevere
0545 un riscontro su quello che state facendo. Lasciate che la comunità
0546 senta che state lavorando con loro, e che non li stiate sfruttando come
0547 discarica per le vostre aggiunte. In ogni caso, non inviate 50 email nello
0548 stesso momento in una lista di discussione, il più delle volte la vostra serie
0549 di modifiche dovrebbe essere più piccola.
0550
0551 I motivi per i quali dovreste frammentare le cose sono i seguenti:
0552
0553 1) Piccole modifiche aumentano le probabilità che vengano accettate,
0554 altrimenti richiederebbe troppo tempo o sforzo nel verificarne
0555 la correttezza. Una modifica di 5 righe può essere accettata da un
0556 manutentore con a mala pena una seconda occhiata. Invece, una modifica da
0557 500 linee può richiedere ore di rilettura per verificarne la correttezza
0558 (il tempo necessario è esponenzialmente proporzionale alla dimensione della
0559 modifica, o giù di lì)
0560
0561 Piccole modifiche sono inoltre molto facili da debuggare quando qualcosa
0562 non va. È molto più facile annullare le modifiche una per una che
0563 dissezionare una patch molto grande dopo la sua sottomissione (e rompere
0564 qualcosa).
0565
0566 2) È importante non solo inviare piccole modifiche, ma anche riscriverle e
0567 semplificarle (o più semplicemente ordinarle) prima di sottoporle.
0568
0569 Qui un'analogia dello sviluppatore kernel Al Viro:
0570
0571 *"Pensate ad un insegnante di matematica che corregge il compito
0572 di uno studente (di matematica). L'insegnante non vuole vedere le
0573 prove e gli errori commessi dallo studente prima che arrivi alla
0574 soluzione. Vuole vedere la risposta più pulita ed elegante
0575 possibile. Un buono studente lo sa, e non presenterebbe mai le
0576 proprie bozze prima prima della soluzione finale"*
0577
0578 *"Lo stesso vale per lo sviluppo del kernel. I manutentori ed i
0579 revisori non vogliono vedere il procedimento che sta dietro al
0580 problema che uno sta risolvendo. Vogliono vedere una soluzione
0581 semplice ed elegante."*
0582
0583 Può essere una vera sfida il saper mantenere l'equilibrio fra una presentazione
0584 elegante della vostra soluzione, lavorare insieme ad una comunità e dibattere
0585 su un lavoro incompleto. Pertanto è bene entrare presto nel processo di
0586 revisione per migliorare il vostro lavoro, ma anche per riuscire a tenere le
0587 vostre modifiche in pezzettini che potrebbero essere già accettate, nonostante
0588 la vostra intera attività non lo sia ancora.
0589
0590 In fine, rendetevi conto che non è accettabile inviare delle modifiche
0591 incomplete con la promessa che saranno "sistemate dopo".
0592
0593
0594 Giustificare le vostre modifiche
0595 --------------------------------
0596
0597 Insieme alla frammentazione delle vostre modifiche, è altrettanto importante
0598 permettere alla comunità Linux di capire perché dovrebbero accettarle.
0599 Nuove funzionalità devono essere motivate come necessarie ed utili.
0600
0601
0602 Documentare le vostre modifiche
0603 -------------------------------
0604
0605 Quando inviate le vostre modifiche, fate particolare attenzione a quello che
0606 scrivete nella vostra email. Questa diventerà il *ChangeLog* per la modifica,
0607 e sarà visibile a tutti per sempre. Dovrebbe descrivere la modifica nella sua
0608 interezza, contenendo:
0609
0610 - perchè la modifica è necessaria
0611 - l'approccio d'insieme alla patch
0612 - dettagli supplementari
0613 - risultati dei test
0614
0615 Per maggiori dettagli su come tutto ciò dovrebbe apparire, riferitevi alla
0616 sezione ChangeLog del documento:
0617
0618 "The Perfect Patch"
0619 http://www.ozlabs.org/~akpm/stuff/tpp.txt
0620
0621 A volte tutto questo è difficile da realizzare. Il perfezionamento di queste
0622 pratiche può richiedere anni (eventualmente). È un processo continuo di
0623 miglioramento che richiede molta pazienza e determinazione. Ma non mollate,
0624 si può fare. Molti lo hanno fatto prima, ed ognuno ha dovuto iniziare dove
0625 siete voi ora.
0626
0627
0628
0629
0630 ----------
0631
0632 Grazie a Paolo Ciarrocchi che ha permesso che la sezione "Development Process"
0633 (https://lwn.net/Articles/94386/) fosse basata sui testi da lui scritti, ed a
0634 Randy Dunlap e Gerrit Huizenga per la lista di cose che dovreste e non
0635 dovreste dire. Grazie anche a Pat Mochel, Hanna Linder, Randy Dunlap,
0636 Kay Sievers, Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook, Andrew Morton,
0637 Andi Kleen, Vadim Lobanov, Jesper Juhl, Adrian Bunk, Keri Harris, Frans Pop,
0638 David A. Wheeler, Junio Hamano, Michael Kerrisk, e Alex Shepard per le
0639 loro revisioni, commenti e contributi. Senza il loro aiuto, questo documento
0640 non sarebbe stato possibile.
0641
0642 Manutentore: Greg Kroah-Hartman <greg@kroah.com>
