Lines Matching +full:un +full:-
1 .. include:: ../disclaimer-ita.rst
14 la comunità di sviluppo del kernel ha elaborato un insieme di convenzioni
17 argomenti con un ragionevole livello di dettaglio; più informazioni possono
19 :ref:`translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`
20 e :ref:`translations/it_IT/process/submit-checklist.rst <it_submitchecklist>`.
24 ------------------
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é
43 ---------------------
45 Ci sono un certo numero di cose che dovreste fare prima di considerare
48 - Verificare il codice fino al massimo che vi è consentito. Usate gli
50 tutte le più ragionevoli combinazioni d'opzioni, usate cross-compilatori
53 - Assicuratevi che il vostro codice sia conforme alla linee guida del
56 - La vostra patch ha delle conseguenze in termini di prestazioni?
58 impatto (anche positivo); un riassunto dei risultati dovrebbe essere
61 - Siate certi d'avere i diritti per pubblicare il codice. Se questo
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
71 -------------------------
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
98 - La serie di patch che pubblicherete, quasi sicuramente, non sarà
101 finale, e quindi separate in parti che abbiano un senso. Gli sviluppatori
105 - Ogni modifica logicamente indipendente dovrebbe essere preparata come una
106 patch separata. Queste modifiche possono essere piccole ("aggiunto un
107 campo in questa struttura") o grandi (l'aggiunta di un driver nuovo,
113 - Giusto per riaffermare quando detto sopra: non mischiate diversi tipi di
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ù
128 - Però, non strafate. Una volta uno sviluppatore pubblicò una serie di 500
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
134 - Potrebbe essere allettante l'idea di aggiungere una nuova infrastruttura
143 perché richiede un certo tempo e soprattutto dopo che il "vero lavoro" è
148 ---------------------------------------
152 un messaggio che spieghi al resto del mondo, in modo chiaro e veloce,
155 - Un campo opzionale "From" col nome dell'autore della patch. Questa riga
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:*
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,
187 Un buon changelog fornisce le informazioni necessarie a tutte queste
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:
207 - La patch stessa, nel formato unificato per patch ("-u"). Usare
208 l'opzione "-p" assocerà alla modifica il nome della funzione alla quale
214 potrà esservi d'aiuto su questo punto; passatelo a diff con l'opzione "-X".
216 Le etichette sopracitate danno un'idea di come una patch prende vita e sono
218 :ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`.
219 Qui di seguito un breve riassunto.
221 Un'etichetta ci può dire quale commit ha introdotto il problema che viene corretto nella patch::
223 … 1f2e3d4c5b6a ("The first line of the commit specified by the first 12 characters of its SHA-1 ID")
225 Un'altra etichetta viene usata per fornire collegamenti a pagine web contenenti
226 maggiori informazioni, per esempio un rapporto circa il baco risolto dalla
227 patch, oppure un documento con le specifiche implementate dalla patch::
229 Link: https://example.com/somewhere.html optional-other-stuff
233 alcuni strumenti come b4 or un *hook* git come quello descritto qui
234 'Documentation/translations/it_IT/maintainer/configure-git.rst'
236 Un terzo tipo di etichetta viene usato per indicare chi ha contribuito allo
239 tag: Full Name <email address> optional-other-stuff
243 - Signed-off-by: questa è la certificazione che lo sviluppatore ha il diritto
247 :ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`.
250 - Co-developed-by: indica che la patch è stata cosviluppata da diversi
253 Ogni Co-developed-by: dev'essere seguito immediatamente da un Signed-off-by:
255 in :ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`.
257 - Acked-by: indica il consenso di un altro sviluppatore (spesso il manutentore
260 - Tested-by: menziona la persona che ha verificato la patch e l'ha trovata
263 - Reviwed-by: menziona lo sviluppatore che ha revisionato la patch; per
265 :ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`
267 - Reported-by: menziona l'utente che ha riportato il problema corretto da
270 funzionavano correttamente. Se esiste un rapporto disponibile sul web, allora
271 L'etichetta dovrebbe essere seguita da un collegamento al suddetto rapporto.
273 - Cc: la persona menzionata ha ricevuto una copia della patch ed ha avuto
278 delle volte anche Reported-by: va bene, ma è sempre meglio chiedere specialmente
282 -------------------
284 Prima di inviare la vostra patch, ci sarebbero ancora un paio di cose di cui
287 - Siete sicuri che il vostro programma di posta non corromperà le patch?
290 non verranno nemmeno esaminate in dettaglio. Se avete un qualsiasi dubbio,
293 :ref:`Documentation/translations/it_IT/process/email-clients.rst <it_email_clients>`
297 - Siete sicuri che la vostra patch non contenga sciocchi errori? Dovreste
300 più intelligente di voi, nonostante sia il risultato di un certa quantità di
315 - I manutentori dei sottosistemi affetti della modifica. Come descritto
319 - Altri sviluppatori che hanno lavorato nello stesso ambiente - specialmente
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
327 è adatto, alla lista linux-kernel
329 - Se state correggendo un baco, pensate se la patch dovrebbe essere inclusa
336 Quando scegliete i destinatari della patch, è bene avere un'idea di chi
341 sotto-sistema che controllano una parte specifica del kernel. Solitamente,
343 c'è un chiaro manutentore, l'ultima spiaggia è spesso Andrew Morton.
345 Le patch devono avere anche un buon oggetto. Il tipico formato per l'oggetto
350 [PATCH nn/mm] subsys: one-line description of the patch
360 ogni patch abbia un changelog completo.
364 come un unico *thread*. Strumenti come git e quilt hanno comandi per inviare
366 e state usando git, per favore state alla larga dall'opzione --chain-reply-to
367 per evitare di creare un annidamento eccessivo.