Lines Matching refs:una
12 presentato alla comunità per una revisione ed eventualmente per la sua
27 C'è sempre una certa resistenza nel pubblicare patch finché non sono
29 Ma quando il lavoro è di una certa complessità, c'è molto da guadagnare
65 con una licenza GPL
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
85 Per facilitare una revisione e una verifica più estesa, potrebbe diventare
92 Solo le modifiche più semplici dovrebbero essere preparate come una singola
93 patch; tutto il resto dovrebbe essere preparato come una serie logica di
106 - Ogni modifica logicamente indipendente dovrebbe essere preparata come una
110 una descrizione in una sola riga. Ogni patch dovrebbe fare modifiche
115 modifiche nella stessa patch. Se una modifica corregge un baco critico
123 parziale di una serie di patch è uno scenario comune nel quale il
129 - Però, non strafate. Una volta uno sviluppatore pubblicò una serie di 500
135 - Potrebbe essere allettante l'idea di aggiungere una nuova infrastruttura
136 come una serie di patch, ma di lasciare questa infrastruttura inutilizzata
140 problema anche se il baco si trova altrove. Possibilmente, quando una
151 Quindi adesso avete una serie perfetta di patch pronte per la pubblicazione,
160 - Una descrizione di una riga che spieghi cosa fa la patch. Questo
170 - Una riga bianca seguita da una descrizione dettagliata della patch.
174 - Una o più righe etichette, con, minimo, una riga *Signed-off-by:*
178 Gli elementi qui sopra, assieme, formano il changelog di una patch.
193 il limite di una sola riga. La descrizione dettagliata può spiegare meglio
194 i temi e fornire maggiori informazioni. Se una patch corregge un baco,
218 sviluppatori sono stati associati allo sviluppo di una patch. Sono descritte
234 Codice che non presenta una firma appropriata non potrà essere integrato.
238 associato all'etichetta From:) quando più persone lavorano ad una patch.
258 - Cc: la persona menzionata ha ricevuto una copia della patch ed ha avuto
284 ragionamenti su come debba essere una patch per il kernel. Se seguire
292 Quando inviate le patch, è importante inviarne una copia a tutte le persone che
306 - Se state rispondendo a un rapporto su un baco, o a una richiesta di
309 - Inviate una copia alle liste di discussione interessate, o, se nient'altro
314 stable@vger.kernel.org dovrebbe riceverne una copia. Aggiungete anche
316 permetterà alla squadra *stable* di ricevere una notifica quando questa
324 sotto-sistema che controllano una parte specifica del kernel. Solitamente,
329 di una patch assomiglia a questo:
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
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