Lines Matching refs:un

14 la comunità di sviluppo del kernel ha elaborato un insieme di convenzioni
17 argomenti con un ragionevole livello di dettaglio; più informazioni possono
27 veramente "pronte". Per semplici patch questo non è un problema.
30 Dovreste considerare l'idea di pubblicare un lavoro incompleto, o anche
31 preparare un ramo git disponibile agli sviluppatori interessati, cosicché
45 Ci sono un certo numero di cose che dovreste fare prima di considerare
58 impatto (anche positivo); un riassunto dei risultati dovrebbe essere
62 lavoro è stato fatto per un datore di lavoro, egli avrà dei diritti su
66 Come regola generale, pensarci un po' di più prima di inviare il codice
80 principale, cominciate da un punto di rilascio ben noto - uno stabile o
81 un -rc - piuttosto che creare il vostro ramo da quello principale in un punto
85 necessaria la produzione di versioni per -mm, linux-next o i sorgenti di un
87 un lavoro significativo nella risoluzione dei conflitti e nella correzione dei
93 modifiche. Spezzettare le patch è un po' un'arte; alcuni sviluppatori
101 finale, e quindi separate in parti che abbiano un senso. Gli sviluppatori
106 patch separata. Queste modifiche possono essere piccole ("aggiunto un
107 campo in questa struttura") o grandi (l'aggiunta di un driver nuovo,
114 modifiche nella stessa patch. Se una modifica corregge un baco critico
119 - Ogni modifica dovrebbe portare ad un kernel che compila e funziona
121 risultato dovrebbe essere comunque un kernel funzionante. L'applicazione
124 risultato è un kernel guasto, renderete la vita degli sviluppatori più
129 patch che modificavano un unico file - un atto che non lo rese la persona
131 può essere ragionevolmente grande fintanto che contenga un singolo
143 perché richiede un certo tempo e soprattutto dopo che il "vero lavoro" è
152 un messaggio che spieghi al resto del mondo, in modo chiaro e veloce,
178 Scrivere un buon changelog è cruciale ma è spesso un'arte trascurata;
180 un changelog dovreste tenere ben presente che molte persone leggeranno
181 le vostre parole. Queste includono i manutentori di un sotto-sistema, e i
185 chiederanno se la patch è la causa di un problema che stanno cercando,
193 i temi e fornire maggiori informazioni. Se una patch corregge un baco,
195 citate un commit aggiungete sia il suo identificativo che il titolo),
196 Se il problema è associabile ad un file di log o all' output del compilatore,
204 Non serve dirlo, un changelog dovrebbe essere il testo usato nel messaggio
205 di commit in un sistema di controllo di versione. Sarà seguito da:
216 Le etichette sopracitate danno un'idea di come una patch prende vita e sono
219 Qui di seguito un breve riassunto.
227 circa il baco risolto dalla patch, oppure un documento con le specifiche
234 alcuni strumenti come b4 or un *hook* git come quello descritto qui
238 Se il collegamento indirizza verso un rapporto su un baco risolto dalla patch,
266 Ogni Co-developed-by: dev'essere seguito immediatamente da un Signed-off-by:
270 - Acked-by: indica il consenso di un altro sviluppatore (spesso il manutentore
284 quella Closes: con un indirizzo al rapporto, a meno che questo non sia
289 Se esiste un rapporto disponibile sul web, allora
290 L'etichetta dovrebbe essere seguita da un collegamento al suddetto rapporto.
303 Prima di inviare la vostra patch, ci sarebbero ancora un paio di cose di cui
309 non verranno nemmeno esaminate in dettaglio. Se avete un qualsiasi dubbio,
319 più intelligente di voi, nonostante sia il risultato di un certa quantità di
342 - Se state rispondendo a un rapporto su un baco, o a una richiesta di
348 - Se state correggendo un baco, pensate se la patch dovrebbe essere inclusa
355 Quando scegliete i destinatari della patch, è bene avere un'idea di chi
362 c'è un chiaro manutentore, l'ultima spiaggia è spesso Andrew Morton.
364 Le patch devono avere anche un buon oggetto. Il tipico formato per l'oggetto
379 ogni patch abbia un changelog completo.
383 come un unico *thread*. Strumenti come git e quilt hanno comandi per inviare
386 per evitare di creare un annidamento eccessivo.