it_IT/process/5.Posting.rst

1 .. include:: ../disclaimer-ita.rst
19 :ref:`translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`
20 e :ref:`translations/it_IT/process/submit-checklist.rst <it_submitchecklist>`.
24 ------------------
29 dai riscontri che la comunità può darvi prima che completiate il lavoro.
43 ---------------------
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?
61  - Siate certi d'avere i diritti per pubblicare il codice.  Se questo
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
98  - La serie di patch che pubblicherete, quasi sicuramente, non sarà
105  - Ogni modifica logicamente indipendente dovrebbe essere preparata come una
113  - Giusto per riaffermare quando detto sopra: non mischiate diversi tipi di
119  - Ogni modifica dovrebbe portare ad un kernel che compila e funziona
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
134  - Potrebbe essere allettante l'idea di aggiungere una nuova infrastruttura
148 ---------------------------------------
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
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:*
181 le vostre parole.  Queste includono i manutentori di un sotto-sistema, e i
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".
218 :ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`.
223 … 1f2e3d4c5b6a ("The first line of the commit specified by the first 12 characters of its SHA-1 ID")
230        Link: https://example.com/somewhere.html  optional-other-stuff
235 'Documentation/translations/it_IT/maintainer/configure-git.rst'
241        Closes: https://example.com/issues/1234  optional-other-stuff
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
285    disponibile sul web. L'etichetta Link: può essere usata in alternativa a
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 -------------------
306  - Siete sicuri che il vostro programma di posta non corromperà le patch?
308    dai programmi di posta non funzioneranno per chi le riceve, e spesso
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
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
360 sotto-sistema che controllano una parte specifica del kernel.  Solitamente,
369 	[PATCH nn/mm] subsys: one-line description of the patch
385 e state usando git, per favore state alla larga dall'opzione --chain-reply-to