1 .. include:: ../disclaimer-ita.rst 2 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 8 Argomenti avanzati 9 ================== 10 11 A questo punto, si spera, dovreste avere un'idea su come funziona il processo 12 di sviluppo. Ma rimane comunque molto da imparare! Questo capitolo copre 13 alcuni argomenti che potrebbero essere utili per gli sviluppatori che stanno 14 per diventare parte integrante del processo di sviluppo del kernel. 15 16 Gestire le modifiche con git 17 ----------------------------- 18 19 L'uso di un sistema distribuito per il controllo delle versioni del kernel 20 ebbe iniziò nel 2002 quando Linux iniziò a provare il programma proprietario 21 BitKeeper. Nonostante l'uso di BitKeeper fosse opinabile, di certo il suo 22 approccio alla gestione dei sorgenti non lo era. Un sistema distribuito per 23 il controllo delle versioni accelerò immediatamente lo sviluppo del kernel. 24 Oggigiorno, ci sono diverse alternative libere a BitKeeper. Per il meglio o il 25 peggio, il progetto del kernel ha deciso di usare git per gestire i sorgenti. 26 27 Gestire le modifiche con git può rendere la vita dello sviluppatore molto 28 più facile, specialmente quando il volume delle modifiche cresce. 29 Git ha anche i suoi lati taglienti che possono essere pericolosi; è uno 30 strumento giovane e potente che è ancora in fase di civilizzazione da parte 31 dei suoi sviluppatori. Questo documento non ha lo scopo di insegnare l'uso 32 di git ai suoi lettori; ci sarebbe materiale a sufficienza per un lungo 33 documento al riguardo. Invece, qui ci concentriamo in particolare su come 34 git è parte del processo di sviluppo del kernel. Gli sviluppatori che 35 desiderassero diventare agili con git troveranno più informazioni ai 36 seguenti indirizzi: 37 38 https://git-scm.com/ 39 40 https://www.kernel.org/pub/software/scm/git/docs/user-manual.html 41 42 e su varie guide che potrete trovare su internet. 43 44 La prima cosa da fare prima di usarlo per produrre patch che saranno 45 disponibili ad altri, è quella di leggere i siti qui sopra e di acquisire una 46 base solida su come funziona git. Uno sviluppatore che sappia usare git 47 dovrebbe essere capace di ottenere una copia del repositorio principale, 48 esplorare la storia della revisione, registrare le modifiche, usare i rami, 49 eccetera. Una certa comprensione degli strumenti git per riscrivere la storia 50 (come ``rebase``) è altrettanto utile. Git ha i propri concetti e la propria 51 terminologia; un nuovo utente dovrebbe conoscere *refs*, *remote branch*, 52 *index*, *fast-forward merge*, *push* e *pull*, *detached head*, eccetera. 53 Il tutto potrebbe essere un po' intimidatorio visto da fuori, ma con un po' 54 di studio i concetti non saranno così difficili da capire. 55 56 Utilizzare git per produrre patch da sottomettere via email può essere 57 un buon esercizio da fare mentre si sta prendendo confidenza con lo strumento. 58 59 Quando sarete in grado di creare rami git che siano guardabili da altri, 60 vi servirà, ovviamente, un server dal quale sia possibile attingere le vostre 61 modifiche. Se avete un server accessibile da Internet, configurarlo per 62 eseguire git-daemon è relativamente semplice . Altrimenti, iniziano a 63 svilupparsi piattaforme che offrono spazi pubblici, e gratuiti (Github, 64 per esempio). Gli sviluppatori permanenti possono ottenere un account 65 su kernel.org, ma non è proprio facile da ottenere; per maggiori informazioni 66 consultate la pagina web https://kernel.org/faq/. 67 68 In git è normale avere a che fare con tanti rami. Ogni linea di sviluppo 69 può essere separata in "rami per argomenti" e gestiti indipendentemente. 70 In git i rami sono facilissimi, per cui non c'è motivo per non usarli 71 in libertà. In ogni caso, non dovreste sviluppare su alcun ramo dal 72 quale altri potrebbero attingere. I rami disponibili pubblicamente dovrebbero 73 essere creati con attenzione; integrate patch dai rami di sviluppo 74 solo quando sono complete e pronte ad essere consegnate - non prima. 75 76 Git offre alcuni strumenti che vi permettono di riscrivere la storia del 77 vostro sviluppo. Una modifica errata (diciamo, una che rompe la bisezione, 78 oppure che ha un qualche tipo di baco evidente) può essere corretta sul posto 79 o fatta sparire completamente dalla storia. Una serie di patch può essere 80 riscritta come se fosse stata scritta in cima al ramo principale di oggi, 81 anche se ci avete lavorato per mesi. Le modifiche possono essere spostate 82 in modo trasparente da un ramo ad un altro. E così via. Un uso giudizioso 83 di git per revisionare la storia può aiutare nella creazione di una serie 84 di patch pulite e con meno problemi. 85 86 Un uso eccessivo può portare ad altri tipi di problemi, tuttavia, oltre 87 alla semplice ossessione per la creazione di una storia del progetto che sia 88 perfetta. Riscrivere la storia riscriverà le patch contenute in quella 89 storia, trasformando un kernel verificato (si spera) in uno da verificare. 90 Ma, oltre a questo, gli sviluppatori non possono collaborare se non condividono 91 la stessa vista sulla storia del progetto; se riscrivete la storia dalla quale 92 altri sviluppatori hanno attinto per i loro repositori, renderete la loro vita 93 molto più difficile. Quindi tenete conto di questa semplice regola generale: 94 la storia che avete esposto ad altri, generalmente, dovrebbe essere vista come 95 immutabile. 96 97 Dunque, una volta che il vostro insieme di patch è stato reso disponibile 98 pubblicamente non dovrebbe essere più sovrascritto. Git tenterà di imporre 99 questa regola, e si rifiuterà di pubblicare nuove patch che non risultino 100 essere dirette discendenti di quelle pubblicate in precedenza (in altre parole, 101 patch che non condividono la stessa storia). È possibile ignorare questo 102 controllo, e ci saranno momenti in cui sarà davvero necessario riscrivere 103 un ramo già pubblicato. Un esempio è linux-next dove le patch vengono 104 spostate da un ramo all'altro al fine di evitare conflitti. Ma questo tipo 105 d'azione dovrebbe essere un'eccezione. Questo è uno dei motivi per cui lo 106 sviluppo dovrebbe avvenire in rami privati (che possono essere sovrascritti 107 quando lo si ritiene necessario) e reso pubblico solo quando è in uno stato 108 avanzato. 109 110 Man mano che il ramo principale (o altri rami su cui avete basato le 111 modifiche) avanza, diventa allettante l'idea di integrare tutte le patch 112 per rimanere sempre aggiornati. Per un ramo privato, il *rebase* può essere 113 un modo semplice per rimanere aggiornati, ma questa non è un'opzione nel 114 momento in cui il vostro ramo è stato esposto al mondo intero. 115 *Merge* occasionali possono essere considerati di buon senso, ma quando 116 diventano troppo frequenti confondono inutilmente la storia. La tecnica 117 suggerita in questi casi è quella di fare *merge* raramente, e più in generale 118 solo nei momenti di rilascio (per esempio gli -rc del ramo principale). 119 Se siete nervosi circa alcune patch in particolare, potete sempre fare 120 dei *merge* di test in un ramo privato. In queste situazioni git "rerere" 121 può essere utile; questo strumento si ricorda come i conflitti di *merge* 122 furono risolti in passato cosicché non dovrete fare lo stesso lavoro due volte. 123 124 Una delle lamentele più grosse e ricorrenti sull'uso di strumenti come git 125 è il grande movimento di patch da un repositorio all'altro che rende 126 facile l'integrazione nel ramo principale di modifiche mediocri, il tutto 127 sotto il naso dei revisori. Gli sviluppatori del kernel tendono ad essere 128 scontenti quando vedono succedere queste cose; preparare un ramo git con 129 patch che non hanno ricevuto alcuna revisione o completamente avulse, potrebbe 130 influire sulla vostra capacita di proporre, in futuro, l'integrazione dei 131 vostri rami. Citando Linus 132 133 :: 134 135 Potete inviarmi le vostre patch, ma per far si che io integri una 136 vostra modifica da git, devo sapere che voi sappiate cosa state 137 facendo, e ho bisogno di fidarmi *senza* dover passare tutte 138 le modifiche manualmente una per una. 139 140 (https://lwn.net/Articles/224135/). 141 142 Per evitare queste situazioni, assicuratevi che tutte le patch in un ramo 143 siano strettamente correlate al tema delle modifiche; un ramo "driver fixes" 144 non dovrebbe fare modifiche al codice principale per la gestione della memoria. 145 E, più importante ancora, non usate un repositorio git per tentare di 146 evitare il processo di revisione. Pubblicate un sommario di quello che il 147 vostro ramo contiene sulle liste di discussione più opportune, e , quando 148 sarà il momento, richiedete che il vostro ramo venga integrato in linux-next. 149 150 Se e quando altri inizieranno ad inviarvi patch per essere incluse nel 151 vostro repositorio, non dovete dimenticare di revisionarle. Inoltre 152 assicuratevi di mantenerne le informazioni di paternità; al riguardo git "am" 153 fa del suo meglio, ma potreste dover aggiungere una riga "From:" alla patch 154 nel caso in cui sia arrivata per vie traverse. 155 156 Quando richiedete l'integrazione, siate certi di fornire tutte le informazioni: 157 dov'è il vostro repositorio, quale ramo integrare, e quali cambiamenti si 158 otterranno dall'integrazione. Il comando git request-pull può essere d'aiuto; 159 preparerà una richiesta nel modo in cui gli altri sviluppatori se l'aspettano, 160 e verificherà che vi siate ricordati di pubblicare quelle patch su un 161 server pubblico. 162 163 .. _development_advancedtopics_reviews_it: 164 165 Revisionare le patch 166 -------------------- 167 168 Alcuni lettori potrebbero avere obiezioni sulla presenza di questa sezione 169 negli "argomenti avanzati" sulla base che anche gli sviluppatori principianti 170 dovrebbero revisionare le patch. É certamente vero che non c'è modo 171 migliore di imparare come programmare per il kernel che guardare il codice 172 pubblicato dagli altri. In aggiunta, i revisori sono sempre troppo pochi; 173 guardando il codice potete apportare un significativo contributo all'intero 174 processo. 175 176 Revisionare il codice potrebbe risultare intimidatorio, specialmente per i 177 nuovi arrivati che potrebbero sentirsi un po' nervosi nel questionare 178 il codice - in pubblico - pubblicato da sviluppatori più esperti. Perfino 179 il codice scritto dagli sviluppatori più esperti può essere migliorato. 180 Forse il suggerimento migliore per i revisori (tutti) è questo: formulate 181 i commenti come domande e non come critiche. Chiedere "Come viene rilasciato 182 il *lock* in questo percorso?" funziona sempre molto meglio che 183 "qui la sincronizzazione è sbagliata". 184 185 In caso di disaccordi, può essere utile chiedere una terza opinione. Se dopo 186 pochi scambi la discussione raggiunge un punto morto, allora chiedete ai 187 manutentori o altri revisori di partecipare esprimendo la loro opinione. Spesso 188 vige un silenzio assenso per cui gli altri revisori non intervengono se non gli 189 viene richiesto esplicitamente. L'opinione di più persone avrà sicuramente un 190 peso maggiore. 191 192 Diversi sviluppatori revisioneranno il codice con diversi punti di vista. 193 Alcuni potrebbero concentrarsi principalmente sullo stile del codice e se 194 alcune linee hanno degli spazio bianchi di troppo. Altri si chiederanno 195 se accettare una modifica interamente è una cosa positiva per il kernel 196 o no. E altri ancora si focalizzeranno sui problemi di sincronizzazione, 197 l'uso eccessivo di *stack*, problemi di sicurezza, duplicazione del codice 198 in altri contesti, documentazione, effetti negativi sulle prestazioni, cambi 199 all'ABI dello spazio utente, eccetera. Qualunque tipo di revisione è ben 200 accetta e di valore, se porta ad avere un codice migliore nel kernel. 201 202 Non esistono requisiti particolarmente stringenti per l'uso di etichette come 203 ``Reviewed-by``. Tuttavia, perché la revisione sia efficace ci si aspetta un 204 qualche tipo di messaggio che dica "ho verificato A, B e C nel codice che è 205 appena stato inviato e mi sembra tutto in ordine". Inoltre, questo permette ai 206 manutentori di prendere conoscenza circa una revisione avvenuta per davvero. 207 208 Per finire, la revisione delle patch può diventare un processo negativo, troppo 209 focalizzato sulla ricerca dei problemi. Provate a fare qualche complimento di 210 tanto in tanto, specialmente con i nuovi arrivati.
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.