it_IT/process/2.Process.rst

42 patch di ogni rilascio. All'inizio di ogni ciclo di sviluppo, la
46 patch per un nuovo ciclo di sviluppo (e tutte le più importanti modifiche)
48 1000 modifiche ("patch" o "gruppo di modifiche") al giorno.
150 Il ciclo di vita di una patch
153 Le patch non passano direttamente dalla tastiera dello sviluppatori
155 per assicurare che ogni patch sia di buona qualità e desiderata nel
157 meno importanti, o, nel caso di patch ampie e controverse, va avanti per anni.
162 come una patch viene inserita nel kernel.  Ciò che segue è un'introduzione
166 Una patch attraversa, generalmente, le seguenti fasi:
174  - Prima revisione. Le patch vengono pubblicate sulle liste di discussione
177    emergere problemi rilevanti in una patch.
179  - Revisione più ampia. Quando la patch è quasi pronta per essere inserita
182    patch arriverà nel ramo principale. La patch sarà visibile nei sorgenti
185    più estesa della patch e alla scoperta di problemi d'integrazione
189    anche un lavoro quotidiano, quindi integrare le vostre patch potrebbe
190    non essere la loro priorità più alta.  Se una vostra patch riceve
193    patch non riceve alcuna critica ma non è stata integrata dal
195    i necessari aggiornamenti per mantenere la patch aggiornata al kernel
199  - Inclusione nel ramo principale. Eventualmente, una buona patch verrà
206    toccati dalla patch è aumentato, quindi, ancora una volta, potrebbero
226 Esiste una sola persona che può inserire le patch nel repositorio principale
227 del kernel: Linus Torvalds.  Ma, per esempio, di tutte le 9500 patch
242 (solitamente) accetteranno una patch per l'inclusione nel ramo principale
248 di stilare una lista delle patch, includendo informazioni sull'autore ed
249 altri metadati.  In ogni momento, il manutentore può individuare quale patch
254 selezionato per l'inclusione.  Se Linus acconsente, il flusso di patch si
257 singole patch ricevute durante l'operazione di integrazione varia.
260 selezionino pessime patch.
262 I manutentori di sottosistemi, a turno, possono "prendere" patch
271 Chiaramente, in un sistema come questo, l'inserimento delle patch all'interno
273 patch direttamente a Linus non è la via giusta.
279 La catena di sottosistemi guida il flusso di patch all'interno del kernel,
281 patch pronte per la prossima finestra di integrazione?
282 Gli sviluppatori si interesseranno alle patch in sospeso per verificare
288 kernel.  Uno potrebbe prendere le patch provenienti da tutti i sottosistemi
294 di tutto).  L'-mm integra patch proveniente da una lunga lista di sottosistemi;
295 e ha, inoltre, alcune patch destinate al supporto del debugging.
297 Oltre a questo, -mm contiene una raccolta significativa di patch che sono
298 state selezionate da Andrew direttamente.  Queste patch potrebbero essere
302 se per una patch non esiste una via chiara per entrare nel ramo principale,
303 allora è probabile che finirà in -mm.  Le patch passate per -mm
306 patch andrà nel ramo principale attraverso -mm.
308 La patch -mm correnti sono disponibili nella cartella "mmotm" (-mm of
316 I sorgenti principali per il prossimo ciclo d'integrazione delle patch
326 tutte le patch incorporate durante una finestra di integrazione dovrebbero
367 dipende pesantemente dalla capacità di guidare la raccolta di patch in
378 vasto numero di patch.  Git ha inoltre la reputazione di essere difficile
404 Quilt è un sistema di gestione delle patch, piuttosto che un sistema
408 sottosistema utilizzano quilt per gestire le patch che dovrebbero essere
505 creazione di patch che vanno a sistemare errori di battitura o
507 patch creano un certo livello di rumore che distrae l'intera comunità di