it_IT/process/6.Followthrough.rst

.. 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.

Quello che si sta cercando di dire �� che, quando i revisori vi inviano degli
appunti dovete fare attenzione alle osservazioni tecniche che vi stanno
facendo.  Non lasciate che il loro modo di esprimersi o il vostro orgoglio
impediscano che ci�� accada.  Quando avete dei suggerimenti sulla revisione,
prendetevi il tempo per comprendere cosa il revisore stia cercando di
comunicarvi.  Se possibile, sistemate le cose che il revisore vi chiede di
modificare.  E rispondete al revisore ringraziandolo e spiegando come
intendete fare.

Notate che non dovete per forza essere d'accordo con ogni singola modifica
suggerita dai revisori.  Se credete che il revisore non abbia compreso
il vostro codice, spiegateglielo.  Se avete un'obiezione tecnica da fargli
su di una modifica suggerita, spiegatela inserendo anche la vostra soluzione
al problema.  Se la vostra spiegazione ha senso, il revisore la accetter��.
Tuttavia, la vostra motivazione potrebbe non essere del tutto persuasiva,
specialmente se altri iniziano ad essere d'accordo con il revisore.
Prendetevi quindi un po' di tempo per pensare ancora alla cosa. Pu�� risultare
facile essere accecati dalla propria soluzione al punto che non realizzate che
c'�� qualcosa di fondamentalmente sbagliato o, magari, non state nemmeno
risolvendo il problema giusto.

Andrew Morton suggerisce che ogni suggerimento di revisione che non ��
presente nella modifica del codice dovrebbe essere inserito in un commento
aggiuntivo; ci�� pu�� essere d'aiuto ai futuri revisori nell'evitare domande
che sorgono al primo sguardo.

Un errore fatale �� quello di ignorare i commenti di revisione nella speranza
che se ne andranno.  Non andranno via.  Se pubblicherete nuovamente il
codice senza aver risposto ai commenti ricevuti, probabilmente le vostre
modifiche non andranno da nessuna parte.

Parlando di ripubblicazione del codice: per favore tenete a mente che i
revisori non ricorderanno tutti i dettagli del codice che avete pubblicato
l'ultima volta. Quindi �� sempre una buona idea quella di ricordare ai
revisori le questioni sollevate precedetemene e come le avete risolte.
I revisori non dovrebbero star l�� a cercare all'interno degli archivi per
famigliarizzare con ci�� che �� stato detto l'ultima volta; se li aiutate
in questo senso, saranno di umore migliore quando riguarderanno il vostro
codice.

Se invece avete cercato di far tutto correttamente ma le cose continuano
a non andar bene?  Molti disaccordi di natura tecnica possono essere risolti
attraverso la discussione, ma ci sono volte dove qualcuno deve prendere
una decisione.  Se credete veramente che tale decisione andr�� contro di voi
ingiustamente, potete sempre tentare di rivolgervi a qualcuno pi��
in alto di voi.  Per cose di questo genere la persona con pi�� potere ��
Andrew Morton.  Andrew �� una figura molto rispettata all'interno della
comunit�� di sviluppo del kernel; lui pu�� spesso sbrogliare situazioni che
sembrano irrimediabilmente bloccate.  Rivolgersi ad Andrew non deve essere
fatto alla leggera, e non deve essere fatto prima di aver esplorato tutte
le altre alternative.  E tenete a mente, ovviamente, che nemmeno lui
potrebbe non essere d'accordo con voi.

Cosa accade poi
===============

Se la modifica �� ritenuta un elemento valido da essere aggiunta al kernel,
e una volta che la maggior parte degli appunti dei revisori sono stati
sistemati, il passo successivo solitamente �� quello di entrare in un
sottosistema gestito da un manutentore.  Come ci�� avviene dipende dal
sottosistema medesimo; ogni manutentore ha il proprio modo di fare le cose.
In particolare, ci potrebbero essere diversi sorgenti - uno, magari, dedicato
alle modifiche pianificate per la finestra di fusione successiva, e un altro
per il lavoro di lungo periodo.

Per le modifiche proposte in aree per le quali non esiste un sottosistema
preciso (modifiche di gestione della memoria, per esempio), i sorgenti di
ripiego finiscono per essere -mm.  Ed anche le modifiche che riguardano
pi�� sottosistemi possono finire in quest'ultimo.

L'inclusione nei sorgenti di un sottosistema pu�� comportare per una patch,
un alto livello di visibilit��.  Ora altri sviluppatori che stanno lavorando
in quei medesimi sorgenti avranno le vostre modifiche.  I sottosistemi
solitamente riforniscono anche Linux-next, rendendo i propri contenuti
visibili all'intera comunit�� di sviluppo.  A questo punto, ci sono buone
possibilit�� per voi di ricevere ulteriori commenti da un nuovo gruppo di
revisori; anche a questi commenti dovrete rispondere come avete gi�� fatto per
gli altri.

Ci�� che potrebbe accadere a questo punto, in base alla natura della vostra
modifica, riguarda eventuali conflitti con il lavoro svolto da altri.
Nella peggiore delle situazioni, i conflitti pi�� pesanti tra modifiche possono
concludersi con la messa a lato di alcuni dei lavori svolti cosicch�� le
modifiche restanti possano funzionare ed essere integrate.  Altre volte, la
risoluzione dei conflitti richieder�� del lavoro con altri sviluppatori e,
possibilmente, lo spostamento di alcune patch da dei sorgenti a degli altri
in modo da assicurare che tutto sia applicato in modo pulito.  Questo lavoro
pu�� rivelarsi una spina nel fianco, ma consideratevi fortunati: prima
dell'avvento dei sorgenti linux-next, questi conflitti spesso emergevano solo
durante l'apertura della finestra di integrazione e dovevano essere smaltiti
in fretta.  Ora essi possono essere risolti comodamente, prima dell'apertura
della finestra.

Un giorno, se tutto va bene, vi collegherete e vedrete che la vostra patch
�� stata inserita nel ramo principale de kernel. Congratulazioni!  Terminati
i festeggiamenti (nel frattempo avrete inserito il vostro nome nel file
MAINTAINERS) vale la pena ricordare una piccola cosa, ma importante: il
lavoro non �� ancora finito.  L'inserimento nel ramo principale porta con se
nuove sfide.

Cominciamo con il dire che ora la visibilit�� della vostra modifica ��
ulteriormente cresciuta.  Ci potrebbe portare ad una nuova fase di
commenti dagli sviluppatori che non erano ancora a conoscenza della vostra
patch.  Ignorarli potrebbe essere allettante dato che non ci sono pi��
dubbi sull'integrazione della modifica.  Resistete a tale tentazione, dovete
mantenervi disponibili agli sviluppatori che hanno domande o suggerimenti
per voi.

Ancora pi�� importante: l'inclusione nel ramo principale mette il vostro
codice nelle mani di un gruppo di *tester* molto pi�� esteso.  Anche se avete
contribuito ad un driver per un hardware che non �� ancora disponibile, sarete
sorpresi da quante persone inseriranno il vostro codice nei loro kernel.
E, ovviamente, dove ci sono *tester*, ci saranno anche dei rapporti su
eventuali bachi.

La peggior specie di rapporti sono quelli che indicano delle regressioni.
Se la vostra modifica causa una regressione, avrete un gran numero di
occhi puntati su di voi; la regressione deve essere sistemata il prima
possibile.  Se non vorrete o non sarete capaci di sistemarla (e nessuno
lo far�� per voi), la vostra modifica sar�� quasi certamente rimossa durante
la fase di stabilizzazione.  Oltre alla perdita di tutto il lavoro svolto
per far si che la vostra modifica fosse inserita nel ramo principale,
l'avere una modifica rimossa a causa del fallimento nel sistemare una
regressione, potrebbe rendere pi�� difficile per voi far accettare
il vostro lavoro in futuro.

Dopo che ogni regressione �� stata affrontata, ci potrebbero essere altri
bachi ordinari da "sconfiggere".  Il periodo di stabilizzazione �� la
vostra migliore opportunit�� per sistemare questi bachi e assicurarvi che
il debutto del vostro codice nel ramo principale del kernel sia il pi�� solido
possibile.  Quindi, per favore, rispondete ai rapporti sui bachi e ponete
rimedio, se possibile, a tutti i problemi.  �� a questo che serve il periodo
di stabilizzazione; potete iniziare creando nuove fantastiche modifiche
una volta che ogni problema con le vecchie sia stato risolto.

Non dimenticate che esistono altre pietre miliari che possono generare
rapporti sui bachi: il successivo rilascio stabile, quando una distribuzione
importante usa una versione del kernel nel quale �� presente la vostra
modifica, eccetera.  Il continuare a rispondere a questi rapporti �� fonte di
orgoglio per il vostro lavoro.  Se questa non �� una sufficiente motivazione,
allora, �� anche consigliabile considera che la comunit�� di sviluppo ricorda
gli sviluppatori che hanno perso interesse per il loro codice una volta
integrato.  La prossima volta che pubblicherete una patch, la comunit��
la valuter�� anche sulla base del fatto che non sarete disponibili a
prendervene cura anche nel futuro.


Altre cose che posso accadere
=============================

Un giorno, potreste aprire la vostra email e vedere che qualcuno vi ha
inviato una patch per il vostro codice.  Questo, dopo tutto, �� uno dei
vantaggi di avere il vostro codice "l�� fuori".  Se siete d'accordo con
la modifica, potrete anche inoltrarla ad un manutentore di sottosistema
(assicuratevi di includere la riga "From:" cosicch�� l'attribuzione sia
corretta, e aggiungete una vostra firma "Signed-off-by"), oppure inviate
un "Acked-by:" e lasciate che l'autore originale la invii.

Se non siete d'accordo con la patch, inviate una risposta educata
spiegando il perch��.  Se possibile, dite all'autore quali cambiamenti
servirebbero per rendere la patch accettabile da voi.  C'�� una certa
riluttanza nell'inserire modifiche con un conflitto fra autore
e manutentore del codice, ma solo fino ad un certo punto.  Se siete visti
come qualcuno che blocca un buon lavoro senza motivo, quelle patch vi
passeranno oltre e andranno nel ramo principale in ogni caso. Nel kernel
Linux, nessuno ha potere di veto assoluto su alcun codice.  Eccezione
fatta per Linus, forse.

In rarissime occasioni, potreste vedere qualcosa di completamente diverso:
un altro sviluppatore che pubblica una soluzione differente al vostro
problema.  A questo punto, c'�� una buona probabilit�� che una delle due
modifiche non verr�� integrata, e il "c'ero prima io" non �� considerato
un argomento tecnico rilevante.  Se la modifica di qualcun'altro rimpiazza
la vostra ed entra nel ramo principale, esiste un unico modo di reagire:
siate contenti che il vostro problema sia stato risolto e andate avanti con
il vostro lavoro.  L'avere un vostro lavoro spintonato da parte in questo
modo pu�� essere avvilente e scoraggiante, ma la comunit�� ricorder�� come
avrete reagito anche dopo che avr�� dimenticato quale fu la modifica accettata.