it_IT/process/7.AdvancedTopics.rst

1 .. include:: ../disclaimer-ita.rst
11 A questo punto, si spera, dovreste avere un'idea su come funziona il processo
17 -----------------------------
19 L'uso di un sistema distribuito per il controllo delle versioni del kernel
22 approccio alla gestione dei sorgenti non lo era.  Un sistema distribuito per
32 di git ai suoi lettori; ci sarebbe materiale a sufficienza per un lungo
38 	https://git-scm.com/
40 	https://www.kernel.org/pub/software/scm/git/docs/user-manual.html
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'
57 un buon esercizio da fare mentre si sta prendendo confidenza con lo strumento.
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
64 per esempio).  Gli sviluppatori permanenti possono ottenere un account
74 solo quando sono complete e pronte ad essere consegnate - non prima.
78 oppure che ha un qualche tipo di baco evidente) può essere corretta sul posto
82 in modo trasparente da un ramo ad un altro.  E così via.  Un uso giudizioso
86 Un uso eccessivo può portare ad altri tipi di problemi, tuttavia, oltre
89 storia, trasformando un kernel verificato (si spera) in uno da verificare.
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
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
118 solo nei momenti di rilascio (per esempio gli -rc del ramo principale).
120 dei *merge* di test in un ramo privato.  In queste situazioni git "rerere"
125 è il grande movimento di patch da un repositorio all'altro che rende
128 scontenti quando vedono succedere queste cose; preparare un ramo git con
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"
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
148 sarà il momento, richiedete che il vostro ramo venga integrato in linux-next.
158 otterranno dall'integrazione.  Il comando git request-pull può essere d'aiuto;
160 e verificherà che vi siate ricordati di pubblicare quelle patch su un
166 --------------------
173 guardando il codice potete apportare un significativo contributo all'intero
177 nuovi arrivati che potrebbero sentirsi un po' nervosi nel questionare
178 il codice - in pubblico - pubblicato da sviluppatori più esperti.  Perfino
186 pochi scambi la discussione raggiunge un punto morto, allora chiedete ai
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
200 accetta e di valore, se porta ad avere un codice migliore nel kernel.
203 ``Reviewed-by``. Tuttavia, perché la revisione sia efficace ci si aspetta un
208 Per finire, la revisione delle patch può diventare un processo negativo, troppo