Lines Matching full:patch
15 e di procedure per la pubblicazione delle patch; seguirle renderà la vita
26 C'è sempre una certa resistenza nel pubblicare patch finché non sono
27 veramente "pronte". Per semplici patch questo non è un problema.
37 Poche persone guarderanno delle patch che si sa essere fatte a metà,
42 Prima di creare patch
46 l'invio delle patch alla comunità di sviluppo. Queste cose includono:
56 - La vostra patch ha delle conseguenze in termini di prestazioni?
59 incluso nella patch.
70 Preparazione di una patch
73 La preparazione delle patch per la pubblicazione può richiedere una quantità
77 Le patch devono essere preparate per una specifica versione del kernel.
78 Come regola generale, una patch dovrebbe basarsi sul ramo principale attuale
86 sottosistema. Basare questa patch sui suddetti sorgenti potrebbe richiedere
89 della vostra patch e da quello che succede altrove nel kernel.
92 patch; tutto il resto dovrebbe essere preparato come una serie logica di
93 modifiche. Spezzettare le patch è un po' un'arte; alcuni sviluppatori
98 - La serie di patch che pubblicherete, quasi sicuramente, non sarà
106 patch separata. Queste modifiche possono essere piccole ("aggiunto un
109 una descrizione in una sola riga. Ogni patch dovrebbe fare modifiche
114 modifiche nella stessa patch. Se una modifica corregge un baco critico
120 correttamente; se la vostra serie di patch si interrompe a metà il
122 parziale di una serie di patch è uno scenario comune nel quale il
129 patch che modificavano un unico file - un atto che non lo rese la persona
130 più popolare sulla lista di discussione del kernel. Una singola patch
135 come una serie di patch, ma di lasciare questa infrastruttura inutilizzata
136 finché l'ultima patch della serie non abilita tutto quanto. Quando è
138 regressioni, "bisect" indicherà quest'ultima patch come causa del
140 patch aggiunge del nuovo codice dovrebbe renderlo attivo immediatamente.
142 Lavorare per creare la serie di patch perfetta potrebbe essere frustrante
147 Formattazione delle patch e i changelog
150 Quindi adesso avete una serie perfetta di patch pronte per la pubblicazione,
151 ma il lavoro non è davvero finito. Ogni patch deve essere preparata con
153 il suo scopo. Per ottenerlo, ogni patch sarà composta dai seguenti elementi:
155 - Un campo opzionale "From" col nome dell'autore della patch. Questa riga
156 è necessaria solo se state passando la patch di qualcun altro via email,
159 - Una descrizione di una riga che spieghi cosa fa la patch. Questo
161 scopo della patch senza altre informazioni. Questo messaggio,
163 seguito dallo scopo della patch. Per esempio:
169 - Una riga bianca seguita da una descrizione dettagliata della patch.
174 col nome dall'autore della patch. Queste etichette verranno descritte
177 Gli elementi qui sopra, assieme, formano il changelog di una patch.
182 revisori che devono decidere se la patch debba essere inclusa o no,
183 le distribuzioni e altri manutentori che cercano di valutare se la patch
185 chiederanno se la patch è la causa di un problema che stanno cercando,
191 modifica e la motivazione della patch nel modo migliore possibile nonostante
193 i temi e fornire maggiori informazioni. Se una patch corregge un baco,
207 - La patch stessa, nel formato unificato per patch ("-u"). Usare
211 Dovreste evitare di includere nelle patch delle modifiche per file
216 Le etichette sopracitate danno un'idea di come una patch prende vita e sono
221 Un'etichetta ci può dire quale commit ha introdotto il problema che viene corretto nella patch::
227 circa il baco risolto dalla patch, oppure un documento con le specifiche
228 implementate dalla patch::
232 Alcuni manutentori aggiungono quest'etichetta alla patch per fare riferimento
238 Se il collegamento indirizza verso un rapporto su un baco risolto dalla patch,
250 sviluppo della patch. Tutte queste etichette seguono il formato::
257 di sottomettere la patch per l'integrazione nel kernel. Questo rappresenta
263 - Co-developed-by: indica che la patch è stata cosviluppata da diversi
265 associato all'etichetta From:) quando più persone lavorano ad una patch.
271 del codice in oggetto) all'integrazione della patch nel kernel.
273 - Tested-by: menziona la persona che ha verificato la patch e l'ha trovata
276 - Reviwed-by: menziona lo sviluppatore che ha revisionato la patch; per
281 questa patch; quest'etichetta viene usata per dare credito alle persone che
286 Closes: se la patch corregge solo in parte il problema riportato nel
292 - Cc: la persona menzionata ha ricevuto una copia della patch ed ha avuto
295 State attenti ad aggiungere queste etichette alla vostra patch: solo "Cc:" può
303 Prima di inviare la vostra patch, ci sarebbero ancora un paio di cose di cui
306 - Siete sicuri che il vostro programma di posta non corromperà le patch?
307 Le patch che hanno spazi bianchi in libertà o andate a capo aggiunti
310 inviate la patch a voi stessi e verificate che sia integra.
314 di posta al fine di inviare patch.
316 - Siete sicuri che la vostra patch non contenga sciocchi errori? Dovreste
317 sempre processare le patch con scripts/checkpatch.pl e correggere eventuali
320 ragionamenti su come debba essere una patch per il kernel. Se seguire
323 Le patch dovrebbero essere sempre inviate come testo puro. Per favore non
325 citare parti della patch che si vogliono commentare. Invece, mettete la vostra
326 patch direttamente nel messaggio.
328 Quando inviate le patch, è importante inviarne una copia a tutte le persone che
348 - Se state correggendo un baco, pensate se la patch dovrebbe essere inclusa
351 l'etichetta "Cc: stable@vger.kernel.org" nella patch stessa; questo
355 Quando scegliete i destinatari della patch, è bene avere un'idea di chi
356 pensiate che sia colui che, eventualmente, accetterà la vostra patch e
357 la integrerà. Nonostante sia possibile inviare patch direttamente a
361 vorreste che siano questi manutentori ad integrare le vostre patch. Se non
364 Le patch devono avere anche un buon oggetto. Il tipico formato per l'oggetto
365 di una patch assomiglia a questo:
369 [PATCH nn/mm] subsys: one-line description of the patch
371 dove "nn" è il numero ordinale della patch, "mm" è il numero totale delle patch
373 nn/mm può essere omesso per una serie composta da una singola patch.
375 Se avete una significative serie di patch, è prassi inviare una descrizione
379 ogni patch abbia un changelog completo.
381 In generale, la seconda parte e quelle successive di una patch "composta"
384 gruppi di patch con la struttura appropriata. Se avete una serie lunga