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 Le etichette sopracitate danno un'idea di come una patch prende vita e sono
216 Un'etichetta ci può dire quale commit ha introdotto il problema che viene corretto nella patch::
222 circa il baco risolto dalla patch, oppure un documento con le specifiche
223 implementate dalla patch::
227 Alcuni manutentori aggiungono quest'etichetta alla patch per fare riferimento
233 Se il collegamento indirizza verso un rapporto su un baco risolto dalla patch,
245 sviluppo della patch. Tutte queste etichette seguono il formato::
252 di sottomettere la patch per l'integrazione nel kernel. Questo rappresenta
258 - Co-developed-by: indica che la patch è stata cosviluppata da diversi
260 associato all'etichetta From:) quando più persone lavorano ad una patch.
266 del codice in oggetto) all'integrazione della patch nel kernel.
268 - Tested-by: menziona la persona che ha verificato la patch e l'ha trovata
271 - Reviwed-by: menziona lo sviluppatore che ha revisionato la patch; per
276 questa patch; quest'etichetta viene usata per dare credito alle persone che
281 Closes: se la patch corregge solo in parte il problema riportato nel
287 - Cc: la persona menzionata ha ricevuto una copia della patch ed ha avuto
290 State attenti ad aggiungere queste etichette alla vostra patch: solo "Cc:" può
298 Prima di inviare la vostra patch, ci sarebbero ancora un paio di cose di cui
301 - Siete sicuri che il vostro programma di posta non corromperà le patch?
302 Le patch che hanno spazi bianchi in libertà o andate a capo aggiunti
305 inviate la patch a voi stessi e verificate che sia integra.
309 di posta al fine di inviare patch.
311 - Siete sicuri che la vostra patch non contenga sciocchi errori? Dovreste
312 sempre processare le patch con scripts/checkpatch.pl e correggere eventuali
315 ragionamenti su come debba essere una patch per il kernel. Se seguire
318 Le patch dovrebbero essere sempre inviate come testo puro. Per favore non
320 citare parti della patch che si vogliono commentare. Invece, mettete la vostra
321 patch direttamente nel messaggio.
323 Quando inviate le patch, è importante inviarne una copia a tutte le persone che
343 - Se state correggendo un baco, pensate se la patch dovrebbe essere inclusa
346 l'etichetta "Cc: [email protected]" nella patch stessa; questo
350 Quando scegliete i destinatari della patch, è bene avere un'idea di chi
351 pensiate che sia colui che, eventualmente, accetterà la vostra patch e
352 la integrerà. Nonostante sia possibile inviare patch direttamente a
356 vorreste che siano questi manutentori ad integrare le vostre patch. Se non
359 Le patch devono avere anche un buon oggetto. Il tipico formato per l'oggetto
360 di una patch assomiglia a questo:
364 [PATCH nn/mm] subsys: one-line description of the patch
366 dove "nn" è il numero ordinale della patch, "mm" è il numero totale delle patch
368 nn/mm può essere omesso per una serie composta da una singola patch.
370 Se avete una significative serie di patch, è prassi inviare una descrizione
374 ogni patch abbia un changelog completo.
376 In generale, la seconda parte e quelle successive di una patch "composta"
379 gruppi di patch con la struttura appropriata. Se avete una serie lunga