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 ------------------
26 C'è sempre una certa resistenza nel pubblicare patch finché non sono
27 veramente "pronte".  Per semplici patch questo non è un problema.
30 Dovreste considerare l'idea di pubblicare un lavoro incompleto, o anche
34 Quando pubblicate del codice che non è considerato pronto per l'inclusione,
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?
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à
102    sono interessati in modifiche che siano discrete e indipendenti, non
105  - Ogni modifica logicamente indipendente dovrebbe essere preparata come una
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
119  - Ogni modifica dovrebbe portare ad un kernel che compila e funziona
121    risultato dovrebbe essere comunque un kernel funzionante.  L'applicazione
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
136    finché l'ultima patch della serie non abilita tutto quanto.  Quando è
148 ---------------------------------------
151 ma il lavoro non è davvero finito.  Ogni patch deve essere preparata con
155  - Un campo opzionale "From" col nome dell'autore della patch.  Questa riga
157    ma nel dubbio non fa di certo male aggiungerlo.
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
204 Non serve dirlo, un changelog dovrebbe essere il testo usato nel messaggio
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")
229        Link: https://example.com/somewhere.html  optional-other-stuff
234 'Documentation/translations/it_IT/maintainer/configure-git.rst'
239 	tag: Full Name <email address>  optional-other-stuff
243  - Signed-off-by: questa è la certificazione che lo sviluppatore ha il diritto
244    di sottomettere la patch per l'integrazione nel kernel.  Questo rappresenta
247    :ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`.
248    Codice che non presenta una firma appropriata non potrà essere integrato.
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
269    hanno verificato il codice e ci hanno fatto sapere quando le cose non
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
274    l'opportunità di commentarla.
278 delle volte anche Reported-by: va bene, ma è sempre meglio chiedere specialmente
282 -------------------
287  - Siete sicuri che il vostro programma di posta non corromperà le patch?
289    dai programmi di posta non funzioneranno per chi le riceve, e spesso
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
299    problemi riportati.  Per favore tenete ben presente che checkpatch.pl non è
302    i suggerimenti di checkpatch.pl rende il codice peggiore, allora non fatelo.
304 Le patch dovrebbero essere sempre inviate come testo puro.  Per favore non
311 incoraggia le persone a peccare nell'invio di tante copie; non presumente che
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
332    l'etichetta "Cc: stable@vger.kernel.org" nella patch stessa; questo
339 Linus Torvalds, e lasciare che sia lui ad integrarle,solitamente non è la
341 sotto-sistema che controllano una parte specifica del kernel.  Solitamente,
342 vorreste che siano questi manutentori ad integrare le vostre patch.  Se non
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
357 introduttiva come parte zero.  Tuttavia questa convenzione non è universalmente
358 seguita; se la usate, ricordate che le informazioni nell'introduzione non
366 e state usando git, per favore state alla larga dall'opzione --chain-reply-to