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 patch, oppure un documento con le specifiche implementate dalla patch::
231 Alcuni manutentori aggiungono quest'etichetta alla patch per fare riferimento
237 sviluppo della patch. Tutte queste etichette seguono il formato::
244 di sottomettere la patch per l'integrazione nel kernel. Questo rappresenta
250 - Co-developed-by: indica che la patch è stata cosviluppata da diversi
252 associato all'etichetta From:) quando più persone lavorano ad una patch.
258 del codice in oggetto) all'integrazione della patch nel kernel.
260 - Tested-by: menziona la persona che ha verificato la patch e l'ha trovata
263 - Reviwed-by: menziona lo sviluppatore che ha revisionato la patch; per
268 questa patch; quest'etichetta viene usata per dare credito alle persone
272 - Cc: la persona menzionata ha ricevuto una copia della patch ed ha avuto
275 State attenti ad aggiungere queste etichette alla vostra patch: solo
281 Prima di inviare la vostra patch, ci sarebbero ancora un paio di cose di cui
284 - Siete sicuri che il vostro programma di posta non corromperà le patch?
285 Le patch che hanno spazi bianchi in libertà o andate a capo aggiunti
288 inviate la patch a voi stessi e verificate che sia integra.
292 di posta al fine di inviare patch.
294 - Siete sicuri che la vostra patch non contenga sciocchi errori? Dovreste
295 sempre processare le patch con scripts/checkpatch.pl e correggere eventuali
298 ragionamenti su come debba essere una patch per il kernel. Se seguire
301 Le patch dovrebbero essere sempre inviate come testo puro. Per favore non
303 citare parti della patch che si vogliono commentare. Invece, mettete la vostra
304 patch direttamente nel messaggio.
306 Quando inviate le patch, è importante inviarne una copia a tutte le persone che
326 - Se state correggendo un baco, pensate se la patch dovrebbe essere inclusa
329 l'etichetta "Cc: stable@vger.kernel.org" nella patch stessa; questo
333 Quando scegliete i destinatari della patch, è bene avere un'idea di chi
334 pensiate che sia colui che, eventualmente, accetterà la vostra patch e
335 la integrerà. Nonostante sia possibile inviare patch direttamente a
339 vorreste che siano questi manutentori ad integrare le vostre patch. Se non
342 Le patch devono avere anche un buon oggetto. Il tipico formato per l'oggetto
343 di una patch assomiglia a questo:
347 [PATCH nn/mm] subsys: one-line description of the patch
349 dove "nn" è il numero ordinale della patch, "mm" è il numero totale delle patch
351 nn/mm può essere omesso per una serie composta da una singola patch.
353 Se avete una significative serie di patch, è prassi inviare una descrizione
357 ogni patch abbia un changelog completo.
359 In generale, la seconda parte e quelle successive di una patch "composta"
362 gruppi di patch con la struttura appropriata. Se avete una serie lunga