Lines Matching full:patch
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.
157 Il ciclo di vita di una patch
160 Le patch non passano direttamente dalla tastiera dello sviluppatori
162 per assicurare che ogni patch sia di buona qualità e desiderata nel
164 meno importanti, o, nel caso di patch ampie e controverse, va avanti per anni.
169 come una patch viene inserita nel kernel. Ciò che segue è un'introduzione
173 Una patch attraversa, generalmente, le seguenti fasi:
181 - Prima revisione. Le patch vengono pubblicate sulle liste di discussione
184 emergere problemi rilevanti in una patch.
186 - Revisione più ampia. Quando la patch è quasi pronta per essere inserita
189 patch arriverà nel ramo principale. La patch sarà visibile nei sorgenti
192 più estesa della patch e alla scoperta di problemi d'integrazione
196 anche un lavoro quotidiano, quindi integrare le vostre patch potrebbe
197 non essere la loro priorità più alta. Se una vostra patch riceve
200 patch non riceve alcuna critica ma non è stata integrata dal
202 i necessari aggiornamenti per mantenere la patch aggiornata al kernel
206 - Inclusione nel ramo principale. Eventualmente, una buona patch verrà
213 toccati dalla patch è aumentato, quindi, ancora una volta, potrebbero
233 Esiste una sola persona che può inserire le patch nel repositorio principale
234 del kernel: Linus Torvalds. Ma, per esempio, di tutte le 9500 patch
249 (solitamente) accetteranno una patch per l'inclusione nel ramo principale
255 di stilare una lista delle patch, includendo informazioni sull'autore ed
256 altri metadati. In ogni momento, il manutentore può individuare quale patch
261 selezionato per l'inclusione. Se Linus acconsente, il flusso di patch si
264 singole patch ricevute durante l'operazione di integrazione varia.
267 selezionino pessime patch.
269 I manutentori di sottosistemi, a turno, possono "prendere" patch
278 Chiaramente, in un sistema come questo, l'inserimento delle patch all'interno
280 patch direttamente a Linus non è la via giusta.
286 La catena di sottosistemi guida il flusso di patch all'interno del kernel,
288 patch pronte per la prossima finestra di integrazione?
289 Gli sviluppatori si interesseranno alle patch in sospeso per verificare
295 kernel. Uno potrebbe prendere le patch provenienti da tutti i sottosistemi
301 di tutto). L'-mm integra patch proveniente da una lunga lista di sottosistemi;
302 e ha, inoltre, alcune patch destinate al supporto del debugging.
304 Oltre a questo, -mm contiene una raccolta significativa di patch che sono
305 state selezionate da Andrew direttamente. Queste patch potrebbero essere
309 se per una patch non esiste una via chiara per entrare nel ramo principale,
310 allora è probabile che finirà in -mm. Le patch passate per -mm
313 patch andrà nel ramo principale attraverso -mm.
315 La patch -mm correnti sono disponibili nella cartella "mmotm" (-mm of
323 I sorgenti principali per il prossimo ciclo d'integrazione delle patch
333 tutte le patch incorporate durante una finestra di integrazione dovrebbero
374 dipende pesantemente dalla capacità di guidare la raccolta di patch in
385 vasto numero di patch. Git ha inoltre la reputazione di essere difficile
411 Quilt è un sistema di gestione delle patch, piuttosto che un sistema
415 sottosistema utilizzano quilt per gestire le patch che dovrebbero essere
509 creazione di patch che vanno a sistemare errori di battitura o
511 patch creano un certo livello di rumore che distrae l'intera comunità di