Lines Matching full:per

13 alcuni argomenti che potrebbero essere utili per gli sviluppatori che stanno
14 per diventare parte integrante del processo di sviluppo del kernel.
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
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.
32 di git ai suoi lettori; ci sarebbe materiale a sufficienza per un lungo
44 La prima cosa da fare prima di usarlo per produrre patch che saranno
49 eccetera.  Una certa comprensione degli strumenti git per riscrivere la storia
56 Utilizzare git per produrre patch da sottomettere via email può essere
61 modifiche.  Se avete un server accessibile da Internet, configurarlo per
64 per esempio).  Gli sviluppatori permanenti possono ottenere un account
65 su kernel.org, ma non è proprio facile da ottenere; per maggiori informazioni
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
81 anche se ci avete lavorato per mesi.  Le modifiche possono essere spostate
83 di git per revisionare la storia può aiutare nella creazione di una serie
87 alla semplice ossessione per la creazione di una storia del progetto che sia
92 altri sviluppatori hanno attinto per i loro repositori, renderete la loro vita
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).
135 	Potete inviarmi le vostre patch, ma per far si che io integri una
138 	le modifiche manualmente una per una.
142 Per evitare queste situazioni, assicuratevi che tutte le patch in un ramo
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
150 Se e quando altri inizieranno ad inviarvi patch per essere incluse nel
154 nel caso in cui sia arrivata per vie traverse.
169 migliore di imparare come programmare per il kernel che guardare il codice
174 Revisionare il codice potrebbe risultare intimidatorio, specialmente per i
178 Forse il suggerimento migliore per i revisori (tutti) è questo: formulate
186 se accettare una modifica interamente è una cosa positiva per il kernel