it_IT/process/submitting-patches.rst

11 Una persona o un'azienda che volesse inviare una patch al kernel potrebbe
17 Questo documento contiene un vasto numero di suggerimenti concisi.  Per
22 inviando un driver, allora leggete anche :ref:`Documentation/translations/it_IT/process/submitting-…
29 dovete preparare e documentare un certo numero di patch.  Generalmente, l'uso
35 Se non avete un repositorio coi sorgenti del kernel più recenti, allora usate
44 Guardate l'elemento **T:** per un determinato sottosistema nel file MAINTANERS
48 Esiste ancora la possibilità di scaricare un rilascio del kernel come archivio
68 Per creare una patch per un singolo file, spesso è sufficiente fare::
80 "vergini", o comunque non modificati, e fare un ``diff`` coi vostri.
104 Se non usate ``git``, un'alternativa popolare è ``quilt``
112 Descrivete il vostro problema. Esiste sempre un problema che via ha spinto
113 ha fare il vostro lavoro, che sia la correzione di un baco da una riga o una
122 la maggior parte delle installazioni Linux usa un kernel che arriva dai
127 un incidente di sistema, prestazioni di una regressione, picchi di latenza,
135 un compromesso fra l'uso di CPU, la memoria e la leggibilità; o, quando si
142 in un inglese semplice cosicché i revisori possano verificare che il codice si
145 I manutentori vi saranno grati se scrivete la descrizione della patch in un
147 ``git``, come un "commit log".  Leggete :ref:`it_explicit_in_reply_to`.
149 Risolvete solo un problema per patch.  Se la vostra descrizione inizia ad
150 essere lunga, potrebbe essere un segno che la vostra patch necessita d'essere
156 manutentori di un sottosistema vadano a cercare le versioni precedenti per
158 descrizione devono essere un'unica cosa.  Questo aiuta i manutentori e i
167 Se la patch corregge un baco conosciuto, fare riferimento a quel baco inserendo
195 Se la vostra patch corregge un baco in un commit specifico, per esempio avete
196 trovato un problema usando ``git bisect``, per favore usate l'etichetta
218 Per esempio, se i vostri cambiamenti per un singolo driver includono
221 un aggiornamento dell'API e un nuovo driver che lo sfrutta, allora separateli
225 queste modifiche in una singola patch.  Dunque, un singolo cambiamento logico
232 Se al fine di ottenere un cambiamento completo una patch dipende da un'altra,
240 della vostra serie in un punto qualsiasi; non vi saranno grati se nel mezzo
257 Un'eccezione importante si ha quando del codice viene spostato da un file
258 ad un altro -- in questo caso non dovreste modificare il codice spostato
266 di stile dovrebbe essere visto come una guida, non come un sostituto al
273  - CHECK: le cose necessitano di un pensierino
283 interessati dalle modifiche; date un'occhiata al file MAINTAINERS e alla storia
285 scripts/get_maintainer.pl può esservi d'aiuto.  Se non riuscite a trovare un
293 la lista di discussione dedicata ad un sottosistema; probabilmente lì la vostra
298 vger.kernel.org; potete trovare un loro elenco alla pagina
310 Se avete una patch che corregge un baco di sicurezza che potrebbe essere
311 sfruttato, inviatela a security@kernel.org.  Per bachi importanti, un breve
317 Patch che correggono bachi importanti su un kernel già rilasciato, dovrebbero
351   specifico per un'architettura, dato che le persone copiano, fintanto che
353 - qualsiasi modifica dell'autore/manutentore di un file (in pratica
375 La patch non deve essere un allegato MIME, compresso o meno.  Molti
376 dei più popolari programmi di posta elettronica non trasmettono un allegato
378 Inoltre, un allegato MIME rende l'attività di Linus più laboriosa, diminuendo
402 è un ottimo modo per essere ignorati.  Riscontri o domande che non conducono
403 ad una modifica del codice quasi certamente dovrebbero portare ad un commento
408 ringraziarli per il loro tempo.  Revisionare codice è un lavoro faticoso e che
458         (b) Il contributo è basato su un lavoro precedente che, nei limiti
459             della mia conoscenza, è coperto da un'appropriata licenza
463             un'altra licenza) indicata nel file; oppure
469             contributi sono pubblici e che un registro dei contributi (incluse
486 Se siete un manutentore di un sottosistema o di un ramo, qualche volta dovrete
496 sia nulla di obbligatorio, un modo efficace è quello di indicare il vostro
505 Questa pratica è particolarmente utile se siete i manutentori di un ramo
512 sia comune l'utile pratica di inserire un'indicazione circa l'origine della
523 E qui quello che potrebbe vedersi su un kernel più vecchio dove la patch è
532 Qualunque sia il formato, questa informazione fornisce un importante aiuto
553 integra le patch convertirà un "sì, mi sembra che vada bene" in un Acked-by:
556 Acked-by: non indica l'accettazione di un'intera patch.  Per esempio, quando
557 una patch ha effetti su diversi sottosistemi e ha un Acked-by: da un
616 (su un qualche sistema) dalla persona citata.  Questa etichetta informa i
617 manutentori che qualche verifica è stata fatta, fornisce un mezzo per trovare
647 L'etichetta Reviewed-by è la dichiarazione di un parere sulla bontà di
659 non dovrebbe essere aggiunta senza un permesso esplicito, specialmente se
660 l'idea non è stata pubblicata in un forum pubblico.  Detto ciò, dando credito
664 L'etichetta Fixes: indica che la patch corregge un problema in un commit
665 precedente.  Serve a chiarire l'origine di un baco, il che aiuta la revisione
668 Questo è il modo suggerito per indicare che un baco è stato corretto nella
676 Notate che se state usando un repositorio ``git`` per salvare le vostre patch
714 il contenuto della patch.  La ``summary phrase`` non dovrebbe essere un nome
719 Ricordatevi che la ``summary phrase`` della vostra email diventerà un
730 brevi e descrittivi è una bella sfida, ma questo è quello che fa un riassunto
733 La ``summary phrase`` può avere un'etichetta (*tag*) di prefisso racchiusa fra
761 deve aver senso per un lettore esperto che è ha dimenticato i dettagli della
765 i messaggi di log per la patch che li tratta.  Se la patch corregge un errore
774 Aggiungere il ``diffstat`` dopo ``---`` è un buon uso di questo spazio, per
782 Se includete un ``diffstat`` dopo ``---``, usate le opzioni ``-p 1 -w70``
796 precedente, per esempio per collegare la correzione di un baco con l'e-mail
799 In questo modo versioni multiple di una patch non diventeranno un'ingestibile
800 giungla di riferimenti all'interno dei programmi di posta.  Se un collegamento
808 Se avete una serie di patch, potrebbe essere più conveniente per un manutentore
811 in questo modo richiede un livello di fiducia più alto rispetto a prenderle da
828 Una richiesta di *pull* dovrebbe includere anche un messaggio generico
844 essere un buon modo per trovare sviluppatori che possano firmare la vostra
851 l'opportunità di aggiungere un messaggio di changelog all'etichetta; questo è
873 Greg Kroah-Hartman, "Come scocciare un manutentore di un sottosistema"