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

   1 .. include:: ../disclaimer-ita.rst
   2
   3 :Original: :ref:`Documentation/process/6.Followthrough.rst <development_followthrough>`
   4 :Translator: Alessia Mantegazza <amantegazza@vaga.pv.it>
   5
   6 .. _it_development_followthrough:
   7
   8 =============
   9 Completamento
  10 =============
  11
  12 A questo punto, avete seguito le linee guida fino a questo punto e, con
  13 l'aggiunta delle vostre capacità ingegneristiche, avete pubblicato una serie
  14 perfetta di patch.  Uno dei più grandi errori che possono essere commessi
  15 persino da sviluppatori kernel esperti è quello di concludere che il
  16 lavoro sia ormai finito.  In verità, la pubblicazione delle patch
  17 simboleggia una transizione alla fase successiva del processo, con,
  18 probabilmente, ancora un po' di lavoro da fare.
  19
  20 È raro che una modifica sia così bella alla sua prima pubblicazione che non
  21 ci sia alcuno spazio di miglioramento.  Il programma di sviluppo del kernel
  22 riconosce questo fatto e quindi, è fortemente orientato al miglioramento
  23 del codice pubblicato.  Voi, in qualità di autori del codice, dovrete
  24 lavorare con la comunità del kernel per assicurare che il vostro codice
  25 mantenga gli standard qualitativi richiesti.  Un fallimento in questo
  26 processo è quasi come impedire l'inclusione delle vostre patch nel
  27 ramo principale.
  28
  29 Lavorare con i revisori
  30 =======================
  31
  32 Una patch che abbia una certa rilevanza avrà ricevuto numerosi commenti
  33 da parte di altri sviluppatori dato che avranno revisionato il codice.
  34 Lavorare con i revisori può rivelarsi, per molti sviluppatori, la parte
  35 più intimidatoria del processo di sviluppo del kernel.  La vita può esservi
  36 resa molto più facile se tenete presente alcuni dettagli:
  37
  38  - Se avete descritto la vostra modifica correttamente, i revisori ne
  39    comprenderanno il valore e il perché vi siete presi il disturbo di
  40    scriverla.  Ma tale valore non li tratterrà dal porvi una domanda
  41    fondamentale: come verrà mantenuto questo codice nel kernel nei prossimi
  42    cinque o dieci anni?  Molti dei cambiamenti che potrebbero esservi
  43    richiesti - da piccoli problemi di stile a sostanziali ristesure -
  44    vengono dalla consapevolezza che Linux resterà in circolazione e in
  45    continuo sviluppo ancora per diverse decadi.
  46
  47  - La revisione del codice è un duro lavoro, ed è un mestiere poco
  48    riconosciuto; le persone ricordano chi ha scritto il codice, ma meno
  49    fama è attribuita a chi lo ha revisionato.  Quindi i revisori potrebbero
  50    divenire burberi, specialmente quando vendono i medesimi errori venire
  51    fatti ancora e ancora.  Se ricevete una revisione che vi sembra abbia
  52    un tono arrabbiato, insultante o addirittura offensivo, resistente alla
  53    tentazione di rispondere a tono.  La revisione riguarda il codice e non
  54    la persona, e i revisori non vi stanno attaccando personalmente.
  55
  56  - Similarmente, i revisori del codice non stanno cercando di promuovere
  57    i loro interessi a vostre spese.  Gli sviluppatori del kernel spesso si
  58    aspettano di lavorare sul kernel per anni, ma sanno che il loro datore
  59    di lavoro può cambiare.  Davvero, senza praticamente eccezioni, loro
  60    stanno lavorando per la creazione del miglior kernel possibile; non
  61    stanno cercando di creare un disagio ad aziende concorrenti.
  62
  63 Quello che si sta cercando di dire è che, quando i revisori vi inviano degli
  64 appunti dovete fare attenzione alle osservazioni tecniche che vi stanno
  65 facendo.  Non lasciate che il loro modo di esprimersi o il vostro orgoglio
  66 impediscano che ciò accada.  Quando avete dei suggerimenti sulla revisione,
  67 prendetevi il tempo per comprendere cosa il revisore stia cercando di
  68 comunicarvi.  Se possibile, sistemate le cose che il revisore vi chiede di
  69 modificare.  E rispondete al revisore ringraziandolo e spiegando come
  70 intendete fare.
  71
  72 Notate che non dovete per forza essere d'accordo con ogni singola modifica
  73 suggerita dai revisori.  Se credete che il revisore non abbia compreso
  74 il vostro codice, spiegateglielo.  Se avete un'obiezione tecnica da fargli
  75 su di una modifica suggerita, spiegatela inserendo anche la vostra soluzione
  76 al problema.  Se la vostra spiegazione ha senso, il revisore la accetterà.
  77 Tuttavia, la vostra motivazione potrebbe non essere del tutto persuasiva,
  78 specialmente se altri iniziano ad essere d'accordo con il revisore.
  79 Prendetevi quindi un po' di tempo per pensare ancora alla cosa. Può risultare
  80 facile essere accecati dalla propria soluzione al punto che non realizzate che
  81 c'è qualcosa di fondamentalmente sbagliato o, magari, non state nemmeno
  82 risolvendo il problema giusto.
  83
  84 Andrew Morton suggerisce che ogni suggerimento di revisione che non è
  85 presente nella modifica del codice dovrebbe essere inserito in un commento
  86 aggiuntivo; ciò può essere d'aiuto ai futuri revisori nell'evitare domande
  87 che sorgono al primo sguardo.
  88
  89 Un errore fatale è quello di ignorare i commenti di revisione nella speranza
  90 che se ne andranno.  Non andranno via.  Se pubblicherete nuovamente il
  91 codice senza aver risposto ai commenti ricevuti, probabilmente le vostre
  92 modifiche non andranno da nessuna parte.
  93
  94 Parlando di ripubblicazione del codice: per favore tenete a mente che i
  95 revisori non ricorderanno tutti i dettagli del codice che avete pubblicato
  96 l'ultima volta. Quindi è sempre una buona idea quella di ricordare ai
  97 revisori le questioni sollevate precedetemene e come le avete risolte.
  98 I revisori non dovrebbero star lì a cercare all'interno degli archivi per
  99 famigliarizzare con ciò che è stato detto l'ultima volta; se li aiutate
 100 in questo senso, saranno di umore migliore quando riguarderanno il vostro
 101 codice.
 102
 103 Se invece avete cercato di far tutto correttamente ma le cose continuano
 104 a non andar bene?  Molti disaccordi di natura tecnica possono essere risolti
 105 attraverso la discussione, ma ci sono volte dove qualcuno deve prendere
 106 una decisione.  Se credete veramente che tale decisione andrà contro di voi
 107 ingiustamente, potete sempre tentare di rivolgervi a qualcuno più
 108 in alto di voi.  Per cose di questo genere la persona con più potere è
 109 Andrew Morton.  Andrew è una figura molto rispettata all'interno della
 110 comunità di sviluppo del kernel; lui può spesso sbrogliare situazioni che
 111 sembrano irrimediabilmente bloccate.  Rivolgersi ad Andrew non deve essere
 112 fatto alla leggera, e non deve essere fatto prima di aver esplorato tutte
 113 le altre alternative.  E tenete a mente, ovviamente, che nemmeno lui
 114 potrebbe non essere d'accordo con voi.
 115
 116 Cosa accade poi
 117 ===============
 118
 119 Se la modifica è ritenuta un elemento valido da essere aggiunta al kernel,
 120 e una volta che la maggior parte degli appunti dei revisori sono stati
 121 sistemati, il passo successivo solitamente è quello di entrare in un
 122 sottosistema gestito da un manutentore.  Come ciò avviene dipende dal
 123 sottosistema medesimo; ogni manutentore ha il proprio modo di fare le cose.
 124 In particolare, ci potrebbero essere diversi sorgenti - uno, magari, dedicato
 125 alle modifiche pianificate per la finestra di fusione successiva, e un altro
 126 per il lavoro di lungo periodo.
 127
 128 Per le modifiche proposte in aree per le quali non esiste un sottosistema
 129 preciso (modifiche di gestione della memoria, per esempio), i sorgenti di
 130 ripiego finiscono per essere -mm.  Ed anche le modifiche che riguardano
 131 più sottosistemi possono finire in quest'ultimo.
 132
 133 L'inclusione nei sorgenti di un sottosistema può comportare per una patch,
 134 un alto livello di visibilità.  Ora altri sviluppatori che stanno lavorando
 135 in quei medesimi sorgenti avranno le vostre modifiche.  I sottosistemi
 136 solitamente riforniscono anche Linux-next, rendendo i propri contenuti
 137 visibili all'intera comunità di sviluppo.  A questo punto, ci sono buone
 138 possibilità per voi di ricevere ulteriori commenti da un nuovo gruppo di
 139 revisori; anche a questi commenti dovrete rispondere come avete già fatto per
 140 gli altri.
 141
 142 Ciò che potrebbe accadere a questo punto, in base alla natura della vostra
 143 modifica, riguarda eventuali conflitti con il lavoro svolto da altri.
 144 Nella peggiore delle situazioni, i conflitti più pesanti tra modifiche possono
 145 concludersi con la messa a lato di alcuni dei lavori svolti cosicché le
 146 modifiche restanti possano funzionare ed essere integrate.  Altre volte, la
 147 risoluzione dei conflitti richiederà del lavoro con altri sviluppatori e,
 148 possibilmente, lo spostamento di alcune patch da dei sorgenti a degli altri
 149 in modo da assicurare che tutto sia applicato in modo pulito.  Questo lavoro
 150 può rivelarsi una spina nel fianco, ma consideratevi fortunati: prima
 151 dell'avvento dei sorgenti linux-next, questi conflitti spesso emergevano solo
 152 durante l'apertura della finestra di integrazione e dovevano essere smaltiti
 153 in fretta.  Ora essi possono essere risolti comodamente, prima dell'apertura
 154 della finestra.
 155
 156 Un giorno, se tutto va bene, vi collegherete e vedrete che la vostra patch
 157 è stata inserita nel ramo principale de kernel. Congratulazioni!  Terminati
 158 i festeggiamenti (nel frattempo avrete inserito il vostro nome nel file
 159 MAINTAINERS) vale la pena ricordare una piccola cosa, ma importante: il
 160 lavoro non è ancora finito.  L'inserimento nel ramo principale porta con se
 161 nuove sfide.
 162
 163 Cominciamo con il dire che ora la visibilità della vostra modifica è
 164 ulteriormente cresciuta.  Ci potrebbe portare ad una nuova fase di
 165 commenti dagli sviluppatori che non erano ancora a conoscenza della vostra
 166 patch.  Ignorarli potrebbe essere allettante dato che non ci sono più
 167 dubbi sull'integrazione della modifica.  Resistete a tale tentazione, dovete
 168 mantenervi disponibili agli sviluppatori che hanno domande o suggerimenti
 169 per voi.
 170
 171 Ancora più importante: l'inclusione nel ramo principale mette il vostro
 172 codice nelle mani di un gruppo di *tester* molto più esteso.  Anche se avete
 173 contribuito ad un driver per un hardware che non è ancora disponibile, sarete
 174 sorpresi da quante persone inseriranno il vostro codice nei loro kernel.
 175 E, ovviamente, dove ci sono *tester*, ci saranno anche dei rapporti su
 176 eventuali bachi.
 177
 178 La peggior specie di rapporti sono quelli che indicano delle regressioni.
 179 Se la vostra modifica causa una regressione, avrete un gran numero di
 180 occhi puntati su di voi; la regressione deve essere sistemata il prima
 181 possibile.  Se non vorrete o non sarete capaci di sistemarla (e nessuno
 182 lo farà per voi), la vostra modifica sarà quasi certamente rimossa durante
 183 la fase di stabilizzazione.  Oltre alla perdita di tutto il lavoro svolto
 184 per far si che la vostra modifica fosse inserita nel ramo principale,
 185 l'avere una modifica rimossa a causa del fallimento nel sistemare una
 186 regressione, potrebbe rendere più difficile per voi far accettare
 187 il vostro lavoro in futuro.
 188
 189 Dopo che ogni regressione è stata affrontata, ci potrebbero essere altri
 190 bachi ordinari da "sconfiggere".  Il periodo di stabilizzazione è la
 191 vostra migliore opportunità per sistemare questi bachi e assicurarvi che
 192 il debutto del vostro codice nel ramo principale del kernel sia il più solido
 193 possibile.  Quindi, per favore, rispondete ai rapporti sui bachi e ponete
 194 rimedio, se possibile, a tutti i problemi.  È a questo che serve il periodo
 195 di stabilizzazione; potete iniziare creando nuove fantastiche modifiche
 196 una volta che ogni problema con le vecchie sia stato risolto.
 197
 198 Non dimenticate che esistono altre pietre miliari che possono generare
 199 rapporti sui bachi: il successivo rilascio stabile, quando una distribuzione
 200 importante usa una versione del kernel nel quale è presente la vostra
 201 modifica, eccetera.  Il continuare a rispondere a questi rapporti è fonte di
 202 orgoglio per il vostro lavoro.  Se questa non è una sufficiente motivazione,
 203 allora, è anche consigliabile considera che la comunità di sviluppo ricorda
 204 gli sviluppatori che hanno perso interesse per il loro codice una volta
 205 integrato.  La prossima volta che pubblicherete una patch, la comunità
 206 la valuterà anche sulla base del fatto che non sarete disponibili a
 207 prendervene cura anche nel futuro.
 208
 209
 210 Altre cose che posso accadere
 211 =============================
 212
 213 Un giorno, potreste aprire la vostra email e vedere che qualcuno vi ha
 214 inviato una patch per il vostro codice.  Questo, dopo tutto, è uno dei
 215 vantaggi di avere il vostro codice "là fuori".  Se siete d'accordo con
 216 la modifica, potrete anche inoltrarla ad un manutentore di sottosistema
 217 (assicuratevi di includere la riga "From:" cosicché l'attribuzione sia
 218 corretta, e aggiungete una vostra firma "Signed-off-by"), oppure inviate
 219 un "Acked-by:" e lasciate che l'autore originale la invii.
 220
 221 Se non siete d'accordo con la patch, inviate una risposta educata
 222 spiegando il perché.  Se possibile, dite all'autore quali cambiamenti
 223 servirebbero per rendere la patch accettabile da voi.  C'è una certa
 224 riluttanza nell'inserire modifiche con un conflitto fra autore
 225 e manutentore del codice, ma solo fino ad un certo punto.  Se siete visti
 226 come qualcuno che blocca un buon lavoro senza motivo, quelle patch vi
 227 passeranno oltre e andranno nel ramo principale in ogni caso. Nel kernel
 228 Linux, nessuno ha potere di veto assoluto su alcun codice.  Eccezione
 229 fatta per Linus, forse.
 230
 231 In rarissime occasioni, potreste vedere qualcosa di completamente diverso:
 232 un altro sviluppatore che pubblica una soluzione differente al vostro
 233 problema.  A questo punto, c'è una buona probabilità che una delle due
 234 modifiche non verrà integrata, e il "c'ero prima io" non è considerato
 235 un argomento tecnico rilevante.  Se la modifica di qualcun'altro rimpiazza
 236 la vostra ed entra nel ramo principale, esiste un unico modo di reagire:
 237 siate contenti che il vostro problema sia stato risolto e andate avanti con
 238 il vostro lavoro.  L'avere un vostro lavoro spintonato da parte in questo
 239 modo può essere avvilente e scoraggiante, ma la comunità ricorderà come
 240 avrete reagito anche dopo che avrà dimenticato quale fu la modifica accettata.