0001 .. include:: ../disclaimer-ita.rst
0002
0003 :Original: :ref:`Documentation/process/7.AdvancedTopics.rst <development_advancedtopics>`
0004 :Translator: Federico Vaga <federico.vaga@vaga.pv.it>
0005
0006 .. _it_development_advancedtopics:
0007
0008 Argomenti avanzati
0009 ==================
0010
0011 A questo punto, si spera, dovreste avere un'idea su come funziona il processo
0012 di sviluppo. Ma rimane comunque molto da imparare! Questo capitolo copre
0013 alcuni argomenti che potrebbero essere utili per gli sviluppatori che stanno
0014 per diventare parte integrante del processo di sviluppo del kernel.
0015
0016 Gestire le modifiche con git
0017 -----------------------------
0018
0019 L'uso di un sistema distribuito per il controllo delle versioni del kernel
0020 ebbe iniziò nel 2002 quando Linux iniziò a provare il programma proprietario
0021 BitKeeper. Nonostante l'uso di BitKeeper fosse opinabile, di certo il suo
0022 approccio alla gestione dei sorgenti non lo era. Un sistema distribuito per
0023 il controllo delle versioni accelerò immediatamente lo sviluppo del kernel.
0024 Oggigiorno, ci sono diverse alternative libere a BitKeeper. Per il meglio o il
0025 peggio, il progetto del kernel ha deciso di usare git per gestire i sorgenti.
0026
0027 Gestire le modifiche con git può rendere la vita dello sviluppatore molto
0028 più facile, specialmente quando il volume delle modifiche cresce.
0029 Git ha anche i suoi lati taglienti che possono essere pericolosi; è uno
0030 strumento giovane e potente che è ancora in fase di civilizzazione da parte
0031 dei suoi sviluppatori. Questo documento non ha lo scopo di insegnare l'uso
0032 di git ai suoi lettori; ci sarebbe materiale a sufficienza per un lungo
0033 documento al riguardo. Invece, qui ci concentriamo in particolare su come
0034 git è parte del processo di sviluppo del kernel. Gli sviluppatori che
0035 desiderassero diventare agili con git troveranno più informazioni ai
0036 seguenti indirizzi:
0037
0038 http://git-scm.com/
0039
0040 http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
0041
0042 e su varie guide che potrete trovare su internet.
0043
0044 La prima cosa da fare prima di usarlo per produrre patch che saranno
0045 disponibili ad altri, è quella di leggere i siti qui sopra e di acquisire una
0046 base solida su come funziona git. Uno sviluppatore che sappia usare git
0047 dovrebbe essere capace di ottenere una copia del repositorio principale,
0048 esplorare la storia della revisione, registrare le modifiche, usare i rami,
0049 eccetera. Una certa comprensione degli strumenti git per riscrivere la storia
0050 (come ``rebase``) è altrettanto utile. Git ha i propri concetti e la propria
0051 terminologia; un nuovo utente dovrebbe conoscere *refs*, *remote branch*,
0052 *index*, *fast-forward merge*, *push* e *pull*, *detached head*, eccetera.
0053 Il tutto potrebbe essere un po' intimidatorio visto da fuori, ma con un po'
0054 di studio i concetti non saranno così difficili da capire.
0055
0056 Utilizzare git per produrre patch da sottomettere via email può essere
0057 un buon esercizio da fare mentre si sta prendendo confidenza con lo strumento.
0058
0059 Quando sarete in grado di creare rami git che siano guardabili da altri,
0060 vi servirà, ovviamente, un server dal quale sia possibile attingere le vostre
0061 modifiche. Se avete un server accessibile da Internet, configurarlo per
0062 eseguire git-daemon è relativamente semplice . Altrimenti, iniziano a
0063 svilupparsi piattaforme che offrono spazi pubblici, e gratuiti (Github,
0064 per esempio). Gli sviluppatori permanenti possono ottenere un account
0065 su kernel.org, ma non è proprio facile da ottenere; per maggiori informazioni
0066 consultate la pagina web http://kernel.org/faq/.
0067
0068 In git è normale avere a che fare con tanti rami. Ogni linea di sviluppo
0069 può essere separata in "rami per argomenti" e gestiti indipendentemente.
0070 In git i rami sono facilissimi, per cui non c'è motivo per non usarli
0071 in libertà. In ogni caso, non dovreste sviluppare su alcun ramo dal
0072 quale altri potrebbero attingere. I rami disponibili pubblicamente dovrebbero
0073 essere creati con attenzione; integrate patch dai rami di sviluppo
0074 solo quando sono complete e pronte ad essere consegnate - non prima.
0075
0076 Git offre alcuni strumenti che vi permettono di riscrivere la storia del
0077 vostro sviluppo. Una modifica errata (diciamo, una che rompe la bisezione,
0078 oppure che ha un qualche tipo di baco evidente) può essere corretta sul posto
0079 o fatta sparire completamente dalla storia. Una serie di patch può essere
0080 riscritta come se fosse stata scritta in cima al ramo principale di oggi,
0081 anche se ci avete lavorato per mesi. Le modifiche possono essere spostate
0082 in modo trasparente da un ramo ad un altro. E così via. Un uso giudizioso
0083 di git per revisionare la storia può aiutare nella creazione di una serie
0084 di patch pulite e con meno problemi.
0085
0086 Un uso eccessivo può portare ad altri tipi di problemi, tuttavia, oltre
0087 alla semplice ossessione per la creazione di una storia del progetto che sia
0088 perfetta. Riscrivere la storia riscriverà le patch contenute in quella
0089 storia, trasformando un kernel verificato (si spera) in uno da verificare.
0090 Ma, oltre a questo, gli sviluppatori non possono collaborare se non condividono
0091 la stessa vista sulla storia del progetto; se riscrivete la storia dalla quale
0092 altri sviluppatori hanno attinto per i loro repositori, renderete la loro vita
0093 molto più difficile. Quindi tenete conto di questa semplice regola generale:
0094 la storia che avete esposto ad altri, generalmente, dovrebbe essere vista come
0095 immutabile.
0096
0097 Dunque, una volta che il vostro insieme di patch è stato reso disponibile
0098 pubblicamente non dovrebbe essere più sovrascritto. Git tenterà di imporre
0099 questa regola, e si rifiuterà di pubblicare nuove patch che non risultino
0100 essere dirette discendenti di quelle pubblicate in precedenza (in altre parole,
0101 patch che non condividono la stessa storia). È possibile ignorare questo
0102 controllo, e ci saranno momenti in cui sarà davvero necessario riscrivere
0103 un ramo già pubblicato. Un esempio è linux-next dove le patch vengono
0104 spostate da un ramo all'altro al fine di evitare conflitti. Ma questo tipo
0105 d'azione dovrebbe essere un'eccezione. Questo è uno dei motivi per cui lo
0106 sviluppo dovrebbe avvenire in rami privati (che possono essere sovrascritti
0107 quando lo si ritiene necessario) e reso pubblico solo quando è in uno stato
0108 avanzato.
0109
0110 Man mano che il ramo principale (o altri rami su cui avete basato le
0111 modifiche) avanza, diventa allettante l'idea di integrare tutte le patch
0112 per rimanere sempre aggiornati. Per un ramo privato, il *rebase* può essere
0113 un modo semplice per rimanere aggiornati, ma questa non è un'opzione nel
0114 momento in cui il vostro ramo è stato esposto al mondo intero.
0115 *Merge* occasionali possono essere considerati di buon senso, ma quando
0116 diventano troppo frequenti confondono inutilmente la storia. La tecnica
0117 suggerita in questi casi è quella di fare *merge* raramente, e più in generale
0118 solo nei momenti di rilascio (per esempio gli -rc del ramo principale).
0119 Se siete nervosi circa alcune patch in particolare, potete sempre fare
0120 dei *merge* di test in un ramo privato. In queste situazioni git "rerere"
0121 può essere utile; questo strumento si ricorda come i conflitti di *merge*
0122 furono risolti in passato cosicché non dovrete fare lo stesso lavoro due volte.
0123
0124 Una delle lamentele più grosse e ricorrenti sull'uso di strumenti come git
0125 è il grande movimento di patch da un repositorio all'altro che rende
0126 facile l'integrazione nel ramo principale di modifiche mediocri, il tutto
0127 sotto il naso dei revisori. Gli sviluppatori del kernel tendono ad essere
0128 scontenti quando vedono succedere queste cose; preparare un ramo git con
0129 patch che non hanno ricevuto alcuna revisione o completamente avulse, potrebbe
0130 influire sulla vostra capacita di proporre, in futuro, l'integrazione dei
0131 vostri rami. Citando Linus
0132
0133 ::
0134
0135 Potete inviarmi le vostre patch, ma per far si che io integri una
0136 vostra modifica da git, devo sapere che voi sappiate cosa state
0137 facendo, e ho bisogno di fidarmi *senza* dover passare tutte
0138 le modifiche manualmente una per una.
0139
0140 (http://lwn.net/Articles/224135/).
0141
0142 Per evitare queste situazioni, assicuratevi che tutte le patch in un ramo
0143 siano strettamente correlate al tema delle modifiche; un ramo "driver fixes"
0144 non dovrebbe fare modifiche al codice principale per la gestione della memoria.
0145 E, più importante ancora, non usate un repositorio git per tentare di
0146 evitare il processo di revisione. Pubblicate un sommario di quello che il
0147 vostro ramo contiene sulle liste di discussione più opportune, e , quando
0148 sarà il momento, richiedete che il vostro ramo venga integrato in linux-next.
0149
0150 Se e quando altri inizieranno ad inviarvi patch per essere incluse nel
0151 vostro repositorio, non dovete dimenticare di revisionarle. Inoltre
0152 assicuratevi di mantenerne le informazioni di paternità; al riguardo git "am"
0153 fa del suo meglio, ma potreste dover aggiungere una riga "From:" alla patch
0154 nel caso in cui sia arrivata per vie traverse.
0155
0156 Quando richiedete l'integrazione, siate certi di fornire tutte le informazioni:
0157 dov'è il vostro repositorio, quale ramo integrare, e quali cambiamenti si
0158 otterranno dall'integrazione. Il comando git request-pull può essere d'aiuto;
0159 preparerà una richiesta nel modo in cui gli altri sviluppatori se l'aspettano,
0160 e verificherà che vi siate ricordati di pubblicare quelle patch su un
0161 server pubblico.
0162
0163 Revisionare le patch
0164 --------------------
0165
0166 Alcuni lettori potrebbero avere obiezioni sulla presenza di questa sezione
0167 negli "argomenti avanzati" sulla base che anche gli sviluppatori principianti
0168 dovrebbero revisionare le patch. É certamente vero che non c'è modo
0169 migliore di imparare come programmare per il kernel che guardare il codice
0170 pubblicato dagli altri. In aggiunta, i revisori sono sempre troppo pochi;
0171 guardando il codice potete apportare un significativo contributo all'intero
0172 processo.
0173
0174 Revisionare il codice potrebbe risultare intimidatorio, specialmente per i
0175 nuovi arrivati che potrebbero sentirsi un po' nervosi nel questionare
0176 il codice - in pubblico - pubblicato da sviluppatori più esperti. Perfino
0177 il codice scritto dagli sviluppatori più esperti può essere migliorato.
0178 Forse il suggerimento migliore per i revisori (tutti) è questo: formulate
0179 i commenti come domande e non come critiche. Chiedere "Come viene rilasciato
0180 il *lock* in questo percorso?" funziona sempre molto meglio che
0181 "qui la sincronizzazione è sbagliata".
0182
0183 Diversi sviluppatori revisioneranno il codice con diversi punti di vista.
0184 Alcuni potrebbero concentrarsi principalmente sullo stile del codice e se
0185 alcune linee hanno degli spazio bianchi di troppo. Altri si chiederanno
0186 se accettare una modifica interamente è una cosa positiva per il kernel
0187 o no. E altri ancora si focalizzeranno sui problemi di sincronizzazione,
0188 l'uso eccessivo di *stack*, problemi di sicurezza, duplicazione del codice
0189 in altri contesti, documentazione, effetti negativi sulle prestazioni, cambi
0190 all'ABI dello spazio utente, eccetera. Qualunque tipo di revisione è ben
0191 accetta e di valore, se porta ad avere un codice migliore nel kernel.
