it_IT/process/5.Posting.rst

1 .. include:: ../disclaimer-ita.rst
15 e di procedure per la pubblicazione delle patch; seguirle renderà la vita
19 :ref:`translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`
20 e :ref:`translations/it_IT/process/submit-checklist.rst <it_submitchecklist>`.
24 ------------------
26 C'è sempre una certa resistenza nel pubblicare patch finché non sono
27 veramente "pronte".  Per semplici patch questo non è un problema.
37 Poche persone guarderanno delle patch che si sa essere fatte a metà,
42 Prima di creare patch
43 ---------------------
46 l'invio delle patch alla comunità di sviluppo.  Queste cose includono:
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?
59    incluso nella patch.
61  - Siate certi d'avere i diritti per pubblicare il codice.  Se questo
70 Preparazione di una patch
71 -------------------------
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
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
86 sottosistema.  Basare questa patch sui suddetti sorgenti potrebbe richiedere
89 della vostra patch e da quello che succede altrove nel kernel.
92 patch; tutto il resto dovrebbe essere preparato come una serie logica di
93 modifiche.  Spezzettare le patch è un po' un'arte; alcuni sviluppatori
98  - La serie di patch che pubblicherete, quasi sicuramente, non sarà
105  - Ogni modifica logicamente indipendente dovrebbe essere preparata come una
106    patch separata.  Queste modifiche possono essere piccole ("aggiunto un
109    una descrizione in una sola riga.  Ogni patch dovrebbe fare modifiche
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
120    correttamente; se la vostra serie di patch si interrompe a metà il
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
129    patch che modificavano un unico file - un atto che non lo rese la persona
130    più popolare sulla lista di discussione del kernel.  Una singola patch
134  - Potrebbe essere allettante l'idea di aggiungere una nuova infrastruttura
135    come una serie di patch, ma di lasciare questa infrastruttura inutilizzata
136    finché l'ultima patch della serie non abilita tutto quanto.  Quando è
138    regressioni, "bisect" indicherà quest'ultima patch come causa del
140    patch aggiunge del nuovo codice dovrebbe renderlo attivo immediatamente.
142 Lavorare per creare la serie di patch perfetta potrebbe essere frustrante
147 Formattazione delle patch e i changelog
148 ---------------------------------------
150 Quindi adesso avete una serie perfetta di patch pronte per la pubblicazione,
151 ma il lavoro non è davvero finito.  Ogni patch deve essere preparata con
153 il suo scopo.  Per ottenerlo, ogni patch sarà composta dai seguenti elementi:
155  - Un campo opzionale "From" col nome dell'autore della patch.  Questa riga
156    è necessaria solo se state passando la patch di qualcun altro via email,
159  - Una descrizione di una riga che spieghi cosa fa la patch.  Questo
161    scopo della patch senza altre informazioni.  Questo messaggio,
163    seguito dallo scopo della patch.  Per esempio:
169  - Una riga bianca seguita da una descrizione dettagliata della patch.
173  - Una o più righe etichette, con, minimo, una riga *Signed-off-by:*
174    col nome dall'autore della patch.  Queste etichette verranno descritte
177 Gli elementi qui sopra, assieme, formano il changelog di una patch.
181 le vostre parole.  Queste includono i manutentori di un sotto-sistema, e i
182 revisori che devono decidere se la patch debba essere inclusa o no,
183 le distribuzioni e altri manutentori che cercano di valutare se la patch
185 chiederanno se la patch è la causa di un problema che stanno cercando,
191 modifica e la motivazione della patch nel modo migliore possibile nonostante
193 i temi e fornire maggiori informazioni.  Se una patch corregge un baco,
207  - La patch stessa, nel formato unificato per patch ("-u").  Usare
208    l'opzione "-p" assocerà alla modifica il nome della funzione alla quale
211 Dovreste evitare di includere nelle patch delle modifiche per file
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>`.
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")
227 circa il baco risolto dalla patch, oppure un documento con le specifiche
228 implementate dalla patch::
230        Link: https://example.com/somewhere.html  optional-other-stuff
232 Alcuni manutentori aggiungono quest'etichetta alla patch per fare riferimento
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
250 sviluppo della patch. Tutte queste etichette seguono il formato::
252 	tag: Full Name <email address>  optional-other-stuff
256  - Signed-off-by: questa è la certificazione che lo sviluppatore ha il diritto
257    di sottomettere la patch per l'integrazione nel kernel.  Questo rappresenta
260    :ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`.
263  - Co-developed-by: indica che la patch è stata cosviluppata da diversi
265    associato all'etichetta From:) quando più persone lavorano ad una patch.
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
271    del codice in oggetto) all'integrazione della patch nel kernel.
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
281    questa patch; quest'etichetta viene usata per dare credito alle persone che
286    Closes: se la patch corregge solo in parte il problema riportato nel
292  - Cc: la persona menzionata ha ricevuto una copia della patch ed ha avuto
295 State attenti ad aggiungere queste etichette alla vostra patch: solo "Cc:" può
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?
307    Le patch che hanno spazi bianchi in libertà o andate a capo aggiunti
310    inviate la patch a voi stessi e verificate che sia integra.
312    :ref:`Documentation/translations/it_IT/process/email-clients.rst <it_email_clients>`
314    di posta al fine di inviare patch.
316  - Siete sicuri che la vostra patch non contenga sciocchi errori?  Dovreste
317    sempre processare le patch con scripts/checkpatch.pl e correggere eventuali
320    ragionamenti su come debba essere una patch per il kernel.  Se seguire
323 Le patch dovrebbero essere sempre inviate come testo puro.  Per favore non
325 citare parti della patch che si vogliono commentare.  Invece, mettete la vostra
326 patch direttamente nel messaggio.
328 Quando inviate le patch, è importante inviarne una copia a tutte le persone che
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
351    l'etichetta "Cc: stable@vger.kernel.org" nella patch stessa; questo
355 Quando scegliete i destinatari della patch, è bene avere un'idea di chi
356 pensiate che sia colui che, eventualmente, accetterà la vostra patch e
357 la integrerà.  Nonostante sia possibile inviare patch direttamente a
360 sotto-sistema che controllano una parte specifica del kernel.  Solitamente,
361 vorreste che siano questi manutentori ad integrare le vostre patch.  Se non
364 Le patch devono avere anche un buon oggetto.  Il tipico formato per l'oggetto
365 di una patch assomiglia a questo:
369 	[PATCH nn/mm] subsys: one-line description of the patch
371 dove "nn" è il numero ordinale della patch, "mm" è il numero totale delle patch
373 nn/mm può essere omesso per una serie composta da una singola patch.
375 Se avete una significative serie di patch, è prassi inviare una descrizione
379 ogni patch abbia un changelog completo.
381 In generale, la seconda parte e quelle successive di una patch "composta"
384 gruppi di patch con la struttura appropriata.  Se avete una serie lunga
385 e state usando git, per favore state alla larga dall'opzione --chain-reply-to