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
227 circa il baco risolto dalla patch, oppure un documento con le specifiche
230 Link: https://example.com/somewhere.html optional-other-stuff
234 alcuni strumenti come b4 or un *hook* git come quello descritto qui
235 'Documentation/translations/it_IT/maintainer/configure-git.rst'
238 Se il collegamento indirizza verso un rapporto su un baco risolto dalla patch,
241 Closes: https://example.com/issues/1234 optional-other-stuff
249 Un altro tipo di etichetta viene usato per indicare chi ha contribuito allo
252 tag: Full Name <email address> optional-other-stuff
256 - Signed-off-by: questa è la certificazione che lo sviluppatore ha il diritto
260 :ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`.
263 - Co-developed-by: indica che la patch è stata cosviluppata da diversi
266 Ogni Co-developed-by: dev'essere seguito immediatamente da un Signed-off-by:
268 in :ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`.
270 - Acked-by: indica il consenso di un altro sviluppatore (spesso il manutentore
273 - Tested-by: menziona la persona che ha verificato la patch e l'ha trovata
276 - Reviwed-by: menziona lo sviluppatore che ha revisionato la patch; per
278 :ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`
280 - Reported-by: menziona l'utente che ha riportato il problema corretto da
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.
292 - Cc: la persona menzionata ha ricevuto una copia della patch ed ha avuto
297 delle volte anche Reported-by: va bene, ma è sempre meglio chiedere specialmente
301 -------------------
303 Prima di inviare la vostra patch, ci sarebbero ancora un paio di cose di cui
306 - Siete sicuri che il vostro programma di posta non corromperà le patch?
309 non verranno nemmeno esaminate in dettaglio. Se avete un qualsiasi dubbio,
312 :ref:`Documentation/translations/it_IT/process/email-clients.rst <it_email_clients>`
316 - Siete sicuri che la vostra patch non contenga sciocchi errori? Dovreste
319 più intelligente di voi, nonostante sia il risultato di un certa quantità di
334 - I manutentori dei sottosistemi affetti della modifica. Come descritto
338 - Altri sviluppatori che hanno lavorato nello stesso ambiente - specialmente
342 - Se state rispondendo a un rapporto su un baco, o a una richiesta di
345 - Inviate una copia alle liste di discussione interessate, o, se nient'altro
346 è adatto, alla lista linux-kernel
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
360 sotto-sistema che controllano una parte specifica del kernel. Solitamente,
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
369 [PATCH nn/mm] subsys: one-line description of the patch
379 ogni patch abbia un changelog completo.
383 come un unico *thread*. Strumenti come git e quilt hanno comandi per inviare
385 e state usando git, per favore state alla larga dall'opzione --chain-reply-to
386 per evitare di creare un annidamento eccessivo.