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
28 veramente "pronte". Per semplici patch questo non è un problema.
31 Dovreste considerare l'idea di pubblicare un lavoro incompleto, o anche
32 preparare un ramo git disponibile agli sviluppatori interessati, cosicché
46 Ci sono un certo numero di cose che dovreste fare prima di considerare
59 impatto (anche positivo); un riassunto dei risultati dovrebbe essere
63 lavoro è stato fatto per un datore di lavoro, egli avrà dei diritti su
67 Come regola generale, pensarci un po' di più prima di inviare il codice
81 principale, cominciate da un punto di rilascio ben noto - uno stabile o
82 un -rc - piuttosto che creare il vostro ramo da quello principale in un punto
86 necessaria la produzione di versioni per -mm, linux-next o i sorgenti di un
88 un lavoro significativo nella risoluzione dei conflitti e nella correzione dei
94 modifiche. Spezzettare le patch è un po' un'arte; alcuni sviluppatori
102 finale, e quindi separate in parti che abbiano un senso. Gli sviluppatori
107 patch separata. Queste modifiche possono essere piccole ("aggiunto un
108 campo in questa struttura") o grandi (l'aggiunta di un driver nuovo,
115 modifiche nella stessa patch. Se una modifica corregge un baco critico
120 - Ogni modifica dovrebbe portare ad un kernel che compila e funziona
122 risultato dovrebbe essere comunque un kernel funzionante. L'applicazione
125 risultato è un kernel guasto, renderete la vita degli sviluppatori più
130 patch che modificavano un unico file - un atto che non lo rese la persona
132 può essere ragionevolmente grande fintanto che contenga un singolo
144 perché richiede un certo tempo e soprattutto dopo che il "vero lavoro" è
153 un messaggio che spieghi al resto del mondo, in modo chiaro e veloce,
179 Scrivere un buon changelog è cruciale ma è spesso un'arte trascurata;
181 un changelog dovreste tenere ben presente che molte persone leggeranno
182 le vostre parole. Queste includono i manutentori di un sotto-sistema, e i
186 chiederanno se la patch è la causa di un problema che stanno cercando,
194 i temi e fornire maggiori informazioni. Se una patch corregge un baco,
196 citate un commit aggiungete sia il suo identificativo che il titolo),
197 Se il problema è associabile ad un file di log o all' output del compilatore,
205 Non serve dirlo, un changelog dovrebbe essere il testo usato nel messaggio
206 di commit in un sistema di controllo di versione. Sarà seguito da:
220 quello che segue è un breve riassunto. Ognuna di queste righe ha il seguente
239 Ogni Co-developed-by: dev'essere seguito immediatamente da un Signed-off-by:
243 - Acked-by: indica il consenso di un altro sviluppatore (spesso il manutentore
267 Prima di inviare la vostra patch, ci sarebbero ancora un paio di cose di cui
273 non verranno nemmeno esaminate in dettaglio. Se avete un qualsiasi dubbio,
283 più intelligente di voi, nonostante sia il risultato di un certa quantità di
306 - Se state rispondendo a un rapporto su un baco, o a una richiesta di
312 - Se state correggendo un baco, pensate se la patch dovrebbe essere inclusa
319 Quando scegliete i destinatari della patch, è bene avere un'idea di chi
326 c'è un chiaro manutentore, l'ultima spiaggia è spesso Andrew Morton.
328 Le patch devono avere anche un buon oggetto. Il tipico formato per l'oggetto
343 ogni patch abbia un changelog completo.
347 come un unico *thread*. Strumenti come git e quilt hanno comandi per inviare
350 per evitare di creare un annidamento eccessivo.