211 lines · plain
1.. include:: ../disclaimer-ita.rst2 3:Original: :ref:`Documentation/process/7.AdvancedTopics.rst <development_advancedtopics>`4:Translator: Federico Vaga <federico.vaga@vaga.pv.it>5 6.. _it_development_advancedtopics:7 8Argomenti avanzati9==================10 11A questo punto, si spera, dovreste avere un'idea su come funziona il processo12di sviluppo. Ma rimane comunque molto da imparare! Questo capitolo copre13alcuni argomenti che potrebbero essere utili per gli sviluppatori che stanno14per diventare parte integrante del processo di sviluppo del kernel.15 16Gestire le modifiche con git17-----------------------------18 19L'uso di un sistema distribuito per il controllo delle versioni del kernel20ebbe iniziò nel 2002 quando Linux iniziò a provare il programma proprietario21BitKeeper. Nonostante l'uso di BitKeeper fosse opinabile, di certo il suo22approccio alla gestione dei sorgenti non lo era. Un sistema distribuito per23il controllo delle versioni accelerò immediatamente lo sviluppo del kernel.24Oggigiorno, ci sono diverse alternative libere a BitKeeper. Per il meglio o il25peggio, il progetto del kernel ha deciso di usare git per gestire i sorgenti.26 27Gestire le modifiche con git può rendere la vita dello sviluppatore molto28più facile, specialmente quando il volume delle modifiche cresce.29Git ha anche i suoi lati taglienti che possono essere pericolosi; è uno30strumento giovane e potente che è ancora in fase di civilizzazione da parte31dei suoi sviluppatori. Questo documento non ha lo scopo di insegnare l'uso32di git ai suoi lettori; ci sarebbe materiale a sufficienza per un lungo33documento al riguardo. Invece, qui ci concentriamo in particolare su come34git è parte del processo di sviluppo del kernel. Gli sviluppatori che35desiderassero diventare agili con git troveranno più informazioni ai36seguenti indirizzi:37 38 https://git-scm.com/39 40 https://www.kernel.org/pub/software/scm/git/docs/user-manual.html41 42e su varie guide che potrete trovare su internet.43 44La prima cosa da fare prima di usarlo per produrre patch che saranno45disponibili ad altri, è quella di leggere i siti qui sopra e di acquisire una46base solida su come funziona git. Uno sviluppatore che sappia usare git47dovrebbe essere capace di ottenere una copia del repositorio principale,48esplorare la storia della revisione, registrare le modifiche, usare i rami,49eccetera. Una certa comprensione degli strumenti git per riscrivere la storia50(come ``rebase``) è altrettanto utile. Git ha i propri concetti e la propria51terminologia; un nuovo utente dovrebbe conoscere *refs*, *remote branch*,52*index*, *fast-forward merge*, *push* e *pull*, *detached head*, eccetera.53Il tutto potrebbe essere un po' intimidatorio visto da fuori, ma con un po'54di studio i concetti non saranno così difficili da capire.55 56Utilizzare git per produrre patch da sottomettere via email può essere57un buon esercizio da fare mentre si sta prendendo confidenza con lo strumento.58 59Quando sarete in grado di creare rami git che siano guardabili da altri,60vi servirà, ovviamente, un server dal quale sia possibile attingere le vostre61modifiche. Se avete un server accessibile da Internet, configurarlo per62eseguire git-daemon è relativamente semplice . Altrimenti, iniziano a63svilupparsi piattaforme che offrono spazi pubblici, e gratuiti (Github,64per esempio). Gli sviluppatori permanenti possono ottenere un account65su kernel.org, ma non è proprio facile da ottenere; per maggiori informazioni66consultate la pagina web https://kernel.org/faq/.67 68In git è normale avere a che fare con tanti rami. Ogni linea di sviluppo69può essere separata in "rami per argomenti" e gestiti indipendentemente.70In git i rami sono facilissimi, per cui non c'è motivo per non usarli71in libertà. In ogni caso, non dovreste sviluppare su alcun ramo dal72quale altri potrebbero attingere. I rami disponibili pubblicamente dovrebbero73essere creati con attenzione; integrate patch dai rami di sviluppo74solo quando sono complete e pronte ad essere consegnate - non prima.75 76Git offre alcuni strumenti che vi permettono di riscrivere la storia del77vostro sviluppo. Una modifica errata (diciamo, una che rompe la bisezione,78oppure che ha un qualche tipo di baco evidente) può essere corretta sul posto79o fatta sparire completamente dalla storia. Una serie di patch può essere80riscritta come se fosse stata scritta in cima al ramo principale di oggi,81anche se ci avete lavorato per mesi. Le modifiche possono essere spostate82in modo trasparente da un ramo ad un altro. E così via. Un uso giudizioso83di git per revisionare la storia può aiutare nella creazione di una serie84di patch pulite e con meno problemi.85 86Un uso eccessivo può portare ad altri tipi di problemi, tuttavia, oltre87alla semplice ossessione per la creazione di una storia del progetto che sia88perfetta. Riscrivere la storia riscriverà le patch contenute in quella89storia, trasformando un kernel verificato (si spera) in uno da verificare.90Ma, oltre a questo, gli sviluppatori non possono collaborare se non condividono91la stessa vista sulla storia del progetto; se riscrivete la storia dalla quale92altri sviluppatori hanno attinto per i loro repositori, renderete la loro vita93molto più difficile. Quindi tenete conto di questa semplice regola generale:94la storia che avete esposto ad altri, generalmente, dovrebbe essere vista come95immutabile.96 97Dunque, una volta che il vostro insieme di patch è stato reso disponibile98pubblicamente non dovrebbe essere più sovrascritto. Git tenterà di imporre99questa regola, e si rifiuterà di pubblicare nuove patch che non risultino100essere dirette discendenti di quelle pubblicate in precedenza (in altre parole,101patch che non condividono la stessa storia). È possibile ignorare questo102controllo, e ci saranno momenti in cui sarà davvero necessario riscrivere103un ramo già pubblicato. Un esempio è linux-next dove le patch vengono104spostate da un ramo all'altro al fine di evitare conflitti. Ma questo tipo105d'azione dovrebbe essere un'eccezione. Questo è uno dei motivi per cui lo106sviluppo dovrebbe avvenire in rami privati (che possono essere sovrascritti107quando lo si ritiene necessario) e reso pubblico solo quando è in uno stato108avanzato.109 110Man mano che il ramo principale (o altri rami su cui avete basato le111modifiche) avanza, diventa allettante l'idea di integrare tutte le patch112per rimanere sempre aggiornati. Per un ramo privato, il *rebase* può essere113un modo semplice per rimanere aggiornati, ma questa non è un'opzione nel114momento in cui il vostro ramo è stato esposto al mondo intero.115*Merge* occasionali possono essere considerati di buon senso, ma quando116diventano troppo frequenti confondono inutilmente la storia. La tecnica117suggerita in questi casi è quella di fare *merge* raramente, e più in generale118solo nei momenti di rilascio (per esempio gli -rc del ramo principale).119Se siete nervosi circa alcune patch in particolare, potete sempre fare120dei *merge* di test in un ramo privato. In queste situazioni git "rerere"121può essere utile; questo strumento si ricorda come i conflitti di *merge*122furono risolti in passato cosicché non dovrete fare lo stesso lavoro due volte.123 124Una delle lamentele più grosse e ricorrenti sull'uso di strumenti come git125è il grande movimento di patch da un repositorio all'altro che rende126facile l'integrazione nel ramo principale di modifiche mediocri, il tutto127sotto il naso dei revisori. Gli sviluppatori del kernel tendono ad essere128scontenti quando vedono succedere queste cose; preparare un ramo git con129patch che non hanno ricevuto alcuna revisione o completamente avulse, potrebbe130influire sulla vostra capacita di proporre, in futuro, l'integrazione dei131vostri rami. Citando Linus132 133::134 135 Potete inviarmi le vostre patch, ma per far si che io integri una136 vostra modifica da git, devo sapere che voi sappiate cosa state137 facendo, e ho bisogno di fidarmi *senza* dover passare tutte138 le modifiche manualmente una per una.139 140(https://lwn.net/Articles/224135/).141 142Per evitare queste situazioni, assicuratevi che tutte le patch in un ramo143siano strettamente correlate al tema delle modifiche; un ramo "driver fixes"144non dovrebbe fare modifiche al codice principale per la gestione della memoria.145E, più importante ancora, non usate un repositorio git per tentare di146evitare il processo di revisione. Pubblicate un sommario di quello che il147vostro ramo contiene sulle liste di discussione più opportune, e , quando148sarà il momento, richiedete che il vostro ramo venga integrato in linux-next.149 150Se e quando altri inizieranno ad inviarvi patch per essere incluse nel151vostro repositorio, non dovete dimenticare di revisionarle. Inoltre152assicuratevi di mantenerne le informazioni di paternità; al riguardo git "am"153fa del suo meglio, ma potreste dover aggiungere una riga "From:" alla patch154nel caso in cui sia arrivata per vie traverse.155 156Quando richiedete l'integrazione, siate certi di fornire tutte le informazioni:157dov'è il vostro repositorio, quale ramo integrare, e quali cambiamenti si158otterranno dall'integrazione. Il comando git request-pull può essere d'aiuto;159preparerà una richiesta nel modo in cui gli altri sviluppatori se l'aspettano,160e verificherà che vi siate ricordati di pubblicare quelle patch su un161server pubblico.162 163.. _development_advancedtopics_reviews_it:164 165Revisionare le patch166--------------------167 168Alcuni lettori potrebbero avere obiezioni sulla presenza di questa sezione169negli "argomenti avanzati" sulla base che anche gli sviluppatori principianti170dovrebbero revisionare le patch. É certamente vero che non c'è modo171migliore di imparare come programmare per il kernel che guardare il codice172pubblicato dagli altri. In aggiunta, i revisori sono sempre troppo pochi;173guardando il codice potete apportare un significativo contributo all'intero174processo.175 176Revisionare il codice potrebbe risultare intimidatorio, specialmente per i177nuovi arrivati che potrebbero sentirsi un po' nervosi nel questionare178il codice - in pubblico - pubblicato da sviluppatori più esperti. Perfino179il codice scritto dagli sviluppatori più esperti può essere migliorato.180Forse il suggerimento migliore per i revisori (tutti) è questo: formulate181i commenti come domande e non come critiche. Chiedere "Come viene rilasciato182il *lock* in questo percorso?" funziona sempre molto meglio che183"qui la sincronizzazione è sbagliata".184 185In caso di disaccordi, può essere utile chiedere una terza opinione. Se dopo186pochi scambi la discussione raggiunge un punto morto, allora chiedete ai187manutentori o altri revisori di partecipare esprimendo la loro opinione. Spesso188vige un silenzio assenso per cui gli altri revisori non intervengono se non gli189viene richiesto esplicitamente. L'opinione di più persone avrà sicuramente un190peso maggiore.191 192Diversi sviluppatori revisioneranno il codice con diversi punti di vista.193Alcuni potrebbero concentrarsi principalmente sullo stile del codice e se194alcune linee hanno degli spazio bianchi di troppo. Altri si chiederanno195se accettare una modifica interamente è una cosa positiva per il kernel196o no. E altri ancora si focalizzeranno sui problemi di sincronizzazione,197l'uso eccessivo di *stack*, problemi di sicurezza, duplicazione del codice198in altri contesti, documentazione, effetti negativi sulle prestazioni, cambi199all'ABI dello spazio utente, eccetera. Qualunque tipo di revisione è ben200accetta e di valore, se porta ad avere un codice migliore nel kernel.201 202Non esistono requisiti particolarmente stringenti per l'uso di etichette come203``Reviewed-by``. Tuttavia, perché la revisione sia efficace ci si aspetta un204qualche tipo di messaggio che dica "ho verificato A, B e C nel codice che è205appena stato inviato e mi sembra tutto in ordine". Inoltre, questo permette ai206manutentori di prendere conoscenza circa una revisione avvenuta per davvero.207 208Per finire, la revisione delle patch può diventare un processo negativo, troppo209focalizzato sulla ricerca dei problemi. Provate a fare qualche complimento di210tanto in tanto, specialmente con i nuovi arrivati.211