Lines Matching refs:patch
15 e di procedure per la pubblicazione delle patch; seguirle renderà la vita
27 C'è sempre una certa resistenza nel pubblicare patch finché non sono
28 veramente "pronte". Per semplici patch questo non è un problema.
38 Poche persone guarderanno delle patch che si sa essere fatte a metà,
43 Prima di creare patch
47 l'invio delle patch alla comunità di sviluppo. Queste cose includono:
57 - La vostra patch ha delle conseguenze in termini di prestazioni?
60 incluso nella patch.
71 Preparazione di una patch
74 La preparazione delle patch per la pubblicazione può richiedere una quantità
78 Le patch devono essere preparate per una specifica versione del kernel.
79 Come regola generale, una patch dovrebbe basarsi sul ramo principale attuale
87 sottosistema. Basare questa patch sui suddetti sorgenti potrebbe richiedere
90 della vostra patch e da quello che succede altrove nel kernel.
93 patch; tutto il resto dovrebbe essere preparato come una serie logica di
94 modifiche. Spezzettare le patch è un po' un'arte; alcuni sviluppatori
99 - La serie di patch che pubblicherete, quasi sicuramente, non sarà
107 patch separata. Queste modifiche possono essere piccole ("aggiunto un
110 una descrizione in una sola riga. Ogni patch dovrebbe fare modifiche
115 modifiche nella stessa patch. Se una modifica corregge un baco critico
121 correttamente; se la vostra serie di patch si interrompe a metà il
123 parziale di una serie di patch è uno scenario comune nel quale il
130 patch che modificavano un unico file - un atto che non lo rese la persona
131 più popolare sulla lista di discussione del kernel. Una singola patch
136 come una serie di patch, ma di lasciare questa infrastruttura inutilizzata
137 finché l'ultima patch della serie non abilita tutto quanto. Quando è
139 regressioni, "bisect" indicherà quest'ultima patch come causa del
141 patch aggiunge del nuovo codice dovrebbe renderlo attivo immediatamente.
143 Lavorare per creare la serie di patch perfetta potrebbe essere frustrante
148 Formattazione delle patch e i changelog
151 Quindi adesso avete una serie perfetta di patch pronte per la pubblicazione,
152 ma il lavoro non è davvero finito. Ogni patch deve essere preparata con
154 il suo scopo. Per ottenerlo, ogni patch sarà composta dai seguenti elementi:
156 - Un campo opzionale "From" col nome dell'autore della patch. Questa riga
157 è necessaria solo se state passando la patch di qualcun altro via email,
160 - Una descrizione di una riga che spieghi cosa fa la patch. Questo
162 scopo della patch senza altre informazioni. Questo messaggio,
164 seguito dallo scopo della patch. Per esempio:
170 - Una riga bianca seguita da una descrizione dettagliata della patch.
175 col nome dall'autore della patch. Queste etichette verranno descritte
178 Gli elementi qui sopra, assieme, formano il changelog di una patch.
183 revisori che devono decidere se la patch debba essere inclusa o no,
184 le distribuzioni e altri manutentori che cercano di valutare se la patch
186 chiederanno se la patch è la causa di un problema che stanno cercando,
192 modifica e la motivazione della patch nel modo migliore possibile nonostante
194 i temi e fornire maggiori informazioni. Se una patch corregge un baco,
208 - La patch stessa, nel formato unificato per patch ("-u"). Usare
212 Dovreste evitare di includere nelle patch delle modifiche per file
218 sviluppatori sono stati associati allo sviluppo di una patch. Sono descritte
230 di sottomettere la patch per l'integrazione nel kernel. Questo rappresenta
236 - Co-developed-by: indica che la patch è stata cosviluppata da diversi
238 associato all'etichetta From:) quando più persone lavorano ad una patch.
244 del codice in oggetto) all'integrazione della patch nel kernel.
246 - Tested-by: menziona la persona che ha verificato la patch e l'ha trovata
249 - Reviwed-by: menziona lo sviluppatore che ha revisionato la patch; per
254 questa patch; quest'etichetta viene usata per dare credito alle persone
258 - Cc: la persona menzionata ha ricevuto una copia della patch ed ha avuto
261 State attenti ad aggiungere queste etichette alla vostra patch: solo
267 Prima di inviare la vostra patch, ci sarebbero ancora un paio di cose di cui
270 - Siete sicuri che il vostro programma di posta non corromperà le patch?
271 Le patch che hanno spazi bianchi in libertà o andate a capo aggiunti
274 inviate la patch a voi stessi e verificate che sia integra.
278 di posta al fine di inviare patch.
280 - Siete sicuri che la vostra patch non contenga sciocchi errori? Dovreste
281 sempre processare le patch con scripts/checkpatch.pl e correggere eventuali
284 ragionamenti su come debba essere una patch per il kernel. Se seguire
287 Le patch dovrebbero essere sempre inviate come testo puro. Per favore non
289 citare parti della patch che si vogliono commentare. Invece, mettete la vostra
290 patch direttamente nel messaggio.
292 Quando inviate le patch, è importante inviarne una copia a tutte le persone che
312 - Se state correggendo un baco, pensate se la patch dovrebbe essere inclusa
315 l'etichetta "Cc: stable@vger.kernel.org" nella patch stessa; questo
319 Quando scegliete i destinatari della patch, è bene avere un'idea di chi
320 pensiate che sia colui che, eventualmente, accetterà la vostra patch e
321 la integrerà. Nonostante sia possibile inviare patch direttamente a
325 vorreste che siano questi manutentori ad integrare le vostre patch. Se non
328 Le patch devono avere anche un buon oggetto. Il tipico formato per l'oggetto
329 di una patch assomiglia a questo:
333 [PATCH nn/mm] subsys: one-line description of the patch
335 dove "nn" è il numero ordinale della patch, "mm" è il numero totale delle patch
337 nn/mm può essere omesso per una serie composta da una singola patch.
339 Se avete una significative serie di patch, è prassi inviare una descrizione
343 ogni patch abbia un changelog completo.
345 In generale, la seconda parte e quelle successive di una patch "composta"
348 gruppi di patch con la struttura appropriata. Se avete una serie lunga