Documentation/translations/it_IT/process/6.Followthrough.rst

Source file repositories/reference/linux-study-clean/Documentation/translations/it_IT/process/6.Followthrough.rst

File Facts

System
Linux kernel
Corpus path
Documentation/translations/it_IT/process/6.Followthrough.rst
Extension
.rst
Size
14265 bytes
Lines
248
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/6.Followthrough.rst <development_followthrough>`
:Translator: Alessia Mantegazza <amantegazza@vaga.pv.it>

.. _it_development_followthrough:

=============
Completamento
=============

A questo punto, avete seguito le linee guida fino a questo punto e, con
l'aggiunta delle vostre capacità ingegneristiche, avete pubblicato una serie
perfetta di patch.  Uno dei più grandi errori che possono essere commessi
persino da sviluppatori kernel esperti è quello di concludere che il
lavoro sia ormai finito.  In verità, la pubblicazione delle patch
simboleggia una transizione alla fase successiva del processo, con,
probabilmente, ancora un po' di lavoro da fare.

È raro che una modifica sia così bella alla sua prima pubblicazione che non
ci sia alcuno spazio di miglioramento.  Il programma di sviluppo del kernel
riconosce questo fatto e quindi, è fortemente orientato al miglioramento
del codice pubblicato.  Voi, in qualità di autori del codice, dovrete
lavorare con la comunità del kernel per assicurare che il vostro codice
mantenga gli standard qualitativi richiesti.  Un fallimento in questo
processo è quasi come impedire l'inclusione delle vostre patch nel
ramo principale.

Lavorare con i revisori
=======================

Una patch che abbia una certa rilevanza avrà ricevuto numerosi commenti
da parte di altri sviluppatori dato che avranno revisionato il codice.
Lavorare con i revisori può rivelarsi, per molti sviluppatori, la parte
più intimidatoria del processo di sviluppo del kernel.  La vita può esservi
resa molto più facile se tenete presente alcuni dettagli:

 - Se avete descritto la vostra modifica correttamente, i revisori ne
   comprenderanno il valore e il perché vi siete presi il disturbo di
   scriverla.  Ma tale valore non li tratterrà dal porvi una domanda
   fondamentale: come verrà mantenuto questo codice nel kernel nei prossimi
   cinque o dieci anni?  Molti dei cambiamenti che potrebbero esservi
   richiesti - da piccoli problemi di stile a sostanziali ristesure -
   vengono dalla consapevolezza che Linux resterà in circolazione e in
   continuo sviluppo ancora per diverse decadi.

 - La revisione del codice è un duro lavoro, ed è un mestiere poco
   riconosciuto; le persone ricordano chi ha scritto il codice, ma meno
   fama è attribuita a chi lo ha revisionato.  Quindi i revisori potrebbero
   divenire burberi, specialmente quando vendono i medesimi errori venire
   fatti ancora e ancora.  Se ricevete una revisione che vi sembra abbia
   un tono arrabbiato, insultante o addirittura offensivo, resistente alla
   tentazione di rispondere a tono.  La revisione riguarda il codice e non
   la persona, e i revisori non vi stanno attaccando personalmente.

 - Similarmente, i revisori del codice non stanno cercando di promuovere
   i loro interessi a vostre spese.  Gli sviluppatori del kernel spesso si
   aspettano di lavorare sul kernel per anni, ma sanno che il loro datore
   di lavoro può cambiare.  Davvero, senza praticamente eccezioni, loro
   stanno lavorando per la creazione del miglior kernel possibile; non
   stanno cercando di creare un disagio ad aziende concorrenti.

  - Preparatevi a richieste apparentemente sciocche di modifiche allo stile di
    codifica e a richieste di trasferire parte del vostro codice in parti
    condivise del kernel. Uno dei compiti dei manutentori è quello di mantenere
    lo aspetto del codice. A volte questo significa che l'ingegnoso stratagemma
    nel vostro driver per aggirare un problema deve diventare una caratteristica
    generalizzata del kernel pronta per essere riutilizzata.

Quello che si sta cercando di dire è che, quando i revisori vi inviano degli

Annotation

Implementation Notes