Documentation/translations/it_IT/process/5.Posting.rst

Source file repositories/reference/linux-study-clean/Documentation/translations/it_IT/process/5.Posting.rst

File Facts

System
Linux kernel
Corpus path
Documentation/translations/it_IT/process/5.Posting.rst
Extension
.rst
Size
19897 bytes
Lines
382
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. include:: ../disclaimer-ita.rst

:Original: :ref:`Documentation/process/5.Posting.rst <development_posting>`
:Translator: Federico Vaga <federico.vaga@vaga.pv.it>

.. _it_development_posting:

Pubblicare modifiche
====================

Prima o poi arriva il momento in cui il vostro lavoro è pronto per essere
presentato alla comunità per una revisione ed eventualmente per la sua
inclusione nel ramo principale del kernel.  Com'era prevedibile,
la comunità di sviluppo del kernel ha elaborato un insieme di convenzioni
e di procedure per la pubblicazione delle patch; seguirle renderà la vita
più facile a tutti quanti.  Questo documento cercherà di coprire questi
argomenti con un ragionevole livello di dettaglio; più informazioni possono
essere trovare nella cartella 'Documentation', nei file
:ref:`translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`
e :ref:`translations/it_IT/process/submit-checklist.rst <it_submitchecklist>`.


Quando pubblicarle
------------------

C'è sempre una certa resistenza nel pubblicare patch finché non sono
veramente "pronte".  Per semplici patch questo non è un problema.
Ma quando il lavoro è di una certa complessità, c'è molto da guadagnare
dai riscontri che la comunità può darvi prima che completiate il lavoro.
Dovreste considerare l'idea di pubblicare un lavoro incompleto, o anche
preparare un ramo git disponibile agli sviluppatori interessati, cosicché
possano stare al passo col vostro lavoro in qualunque momento.

Quando pubblicate del codice che non è considerato pronto per l'inclusione,
è bene che lo diciate al momento della pubblicazione.  Inoltre, aggiungete
informazioni sulle cose ancora da sviluppare e sui problemi conosciuti.
Poche persone guarderanno delle patch che si sa essere fatte a metà,
ma quelli che lo faranno penseranno di potervi aiutare a condurre il vostro
sviluppo nella giusta direzione.


Prima di creare patch
---------------------

Ci sono un certo numero di cose che dovreste fare prima di considerare
l'invio delle patch alla comunità di sviluppo.  Queste cose includono:

 - Verificare il codice fino al massimo che vi è consentito. Usate gli
   strumenti di debug del kernel, assicuratevi che il kernel compili con
   tutte le più ragionevoli combinazioni d'opzioni, usate cross-compilatori
   per compilare il codice per differenti architetture, eccetera.

 - Assicuratevi che il vostro codice sia conforme alla linee guida del
   kernel sullo stile del codice.

 - La vostra patch ha delle conseguenze in termini di prestazioni?
   Se è così, dovreste eseguire dei *benchmark* che mostrino il loro
   impatto (anche positivo); un riassunto dei risultati dovrebbe essere
   incluso nella patch.

 - Siate certi d'avere i diritti per pubblicare il codice.  Se questo
   lavoro è stato fatto per un datore di lavoro, egli avrà dei diritti su
   questo lavoro e dovrà quindi essere d'accordo alla sua pubblicazione
   con una licenza GPL

Come regola generale, pensarci un po' di più prima di inviare il codice
ripaga quasi sempre lo sforzo.


Preparazione di una patch

Annotation

Implementation Notes