Lines Matching refs:una
12 presentato alla comunità per una revisione ed eventualmente per la sua
26 C'è sempre una certa resistenza nel pubblicare patch finché non sono
28 Ma quando il lavoro è di una certa complessità, c'è molto da guadagnare
64 con una licenza GPL
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
84 Per facilitare una revisione e una verifica più estesa, potrebbe diventare
91 Solo le modifiche più semplici dovrebbero essere preparate come una singola
92 patch; tutto il resto dovrebbe essere preparato come una serie logica di
105 - Ogni modifica logicamente indipendente dovrebbe essere preparata come una
109 una descrizione in una sola riga. Ogni patch dovrebbe fare modifiche
114 modifiche nella stessa patch. Se una modifica corregge un baco critico
122 parziale di una serie di patch è uno scenario comune nel quale il
128 - Però, non strafate. Una volta uno sviluppatore pubblicò una serie di 500
134 - Potrebbe essere allettante l'idea di aggiungere una nuova infrastruttura
135 come una serie di patch, ma di lasciare questa infrastruttura inutilizzata
139 problema anche se il baco si trova altrove. Possibilmente, quando una
150 Quindi adesso avete una serie perfetta di patch pronte per la pubblicazione,
159 - Una descrizione di una riga che spieghi cosa fa la patch. Questo
169 - Una riga bianca seguita da una descrizione dettagliata della patch.
173 - Una o più righe etichette, con, minimo, una riga *Signed-off-by:*
177 Gli elementi qui sopra, assieme, formano il changelog di una patch.
192 il limite di una sola riga. La descrizione dettagliata può spiegare meglio
193 i temi e fornire maggiori informazioni. Se una patch corregge un baco,
216 Le etichette sopracitate danno un'idea di come una patch prende vita e sono
248 Codice che non presenta una firma appropriata non potrà essere integrato.
252 associato all'etichetta From:) quando più persone lavorano ad una patch.
273 - Cc: la persona menzionata ha ricevuto una copia della patch ed ha avuto
279 se il baco è stato riportato in una comunicazione privata.
301 ragionamenti su come debba essere una patch per il kernel. Se seguire
309 Quando inviate le patch, è importante inviarne una copia a tutte le persone che
323 - Se state rispondendo a un rapporto su un baco, o a una richiesta di
326 - Inviate una copia alle liste di discussione interessate, o, se nient'altro
331 stable@vger.kernel.org dovrebbe riceverne una copia. Aggiungete anche
333 permetterà alla squadra *stable* di ricevere una notifica quando questa
341 sotto-sistema che controllano una parte specifica del kernel. Solitamente,
346 di una patch assomiglia a questo:
354 nn/mm può essere omesso per una serie composta da una singola patch.
356 Se avete una significative serie di patch, è prassi inviare una descrizione
362 In generale, la seconda parte e quelle successive di una patch "composta"
365 gruppi di patch con la struttura appropriata. Se avete una serie lunga