0001 .. include:: ../disclaimer-ita.rst
0002
0003 :Original: :ref:`Documentation/process/6.Followthrough.rst <development_followthrough>`
0004 :Translator: Alessia Mantegazza <amantegazza@vaga.pv.it>
0005
0006 .. _it_development_followthrough:
0007
0008 =============
0009 Completamento
0010 =============
0011
0012 A questo punto, avete seguito le linee guida fino a questo punto e, con
0013 l'aggiunta delle vostre capacità ingegneristiche, avete pubblicato una serie
0014 perfetta di patch. Uno dei più grandi errori che possono essere commessi
0015 persino da sviluppatori kernel esperti è quello di concludere che il
0016 lavoro sia ormai finito. In verità, la pubblicazione delle patch
0017 simboleggia una transizione alla fase successiva del processo, con,
0018 probabilmente, ancora un po' di lavoro da fare.
0019
0020 È raro che una modifica sia così bella alla sua prima pubblicazione che non
0021 ci sia alcuno spazio di miglioramento. Il programma di sviluppo del kernel
0022 riconosce questo fatto e quindi, è fortemente orientato al miglioramento
0023 del codice pubblicato. Voi, in qualità di autori del codice, dovrete
0024 lavorare con la comunità del kernel per assicurare che il vostro codice
0025 mantenga gli standard qualitativi richiesti. Un fallimento in questo
0026 processo è quasi come impedire l'inclusione delle vostre patch nel
0027 ramo principale.
0028
0029 Lavorare con i revisori
0030 =======================
0031
0032 Una patch che abbia una certa rilevanza avrà ricevuto numerosi commenti
0033 da parte di altri sviluppatori dato che avranno revisionato il codice.
0034 Lavorare con i revisori può rivelarsi, per molti sviluppatori, la parte
0035 più intimidatoria del processo di sviluppo del kernel. La vita può esservi
0036 resa molto più facile se tenete presente alcuni dettagli:
0037
0038 - Se avete descritto la vostra modifica correttamente, i revisori ne
0039 comprenderanno il valore e il perché vi siete presi il disturbo di
0040 scriverla. Ma tale valore non li tratterrà dal porvi una domanda
0041 fondamentale: come verrà mantenuto questo codice nel kernel nei prossimi
0042 cinque o dieci anni? Molti dei cambiamenti che potrebbero esservi
0043 richiesti - da piccoli problemi di stile a sostanziali ristesure -
0044 vengono dalla consapevolezza che Linux resterà in circolazione e in
0045 continuo sviluppo ancora per diverse decadi.
0046
0047 - La revisione del codice è un duro lavoro, ed è un mestiere poco
0048 riconosciuto; le persone ricordano chi ha scritto il codice, ma meno
0049 fama è attribuita a chi lo ha revisionato. Quindi i revisori potrebbero
0050 divenire burberi, specialmente quando vendono i medesimi errori venire
0051 fatti ancora e ancora. Se ricevete una revisione che vi sembra abbia
0052 un tono arrabbiato, insultante o addirittura offensivo, resistente alla
0053 tentazione di rispondere a tono. La revisione riguarda il codice e non
0054 la persona, e i revisori non vi stanno attaccando personalmente.
0055
0056 - Similarmente, i revisori del codice non stanno cercando di promuovere
0057 i loro interessi a vostre spese. Gli sviluppatori del kernel spesso si
0058 aspettano di lavorare sul kernel per anni, ma sanno che il loro datore
0059 di lavoro può cambiare. Davvero, senza praticamente eccezioni, loro
0060 stanno lavorando per la creazione del miglior kernel possibile; non
0061 stanno cercando di creare un disagio ad aziende concorrenti.
0062
0063 Quello che si sta cercando di dire è che, quando i revisori vi inviano degli
0064 appunti dovete fare attenzione alle osservazioni tecniche che vi stanno
0065 facendo. Non lasciate che il loro modo di esprimersi o il vostro orgoglio
0066 impediscano che ciò accada. Quando avete dei suggerimenti sulla revisione,
0067 prendetevi il tempo per comprendere cosa il revisore stia cercando di
0068 comunicarvi. Se possibile, sistemate le cose che il revisore vi chiede di
0069 modificare. E rispondete al revisore ringraziandolo e spiegando come
0070 intendete fare.
0071
0072 Notate che non dovete per forza essere d'accordo con ogni singola modifica
0073 suggerita dai revisori. Se credete che il revisore non abbia compreso
0074 il vostro codice, spiegateglielo. Se avete un'obiezione tecnica da fargli
0075 su di una modifica suggerita, spiegatela inserendo anche la vostra soluzione
0076 al problema. Se la vostra spiegazione ha senso, il revisore la accetterà.
0077 Tuttavia, la vostra motivazione potrebbe non essere del tutto persuasiva,
0078 specialmente se altri iniziano ad essere d'accordo con il revisore.
0079 Prendetevi quindi un po' di tempo per pensare ancora alla cosa. Può risultare
0080 facile essere accecati dalla propria soluzione al punto che non realizzate che
0081 c'è qualcosa di fondamentalmente sbagliato o, magari, non state nemmeno
0082 risolvendo il problema giusto.
0083
0084 Andrew Morton suggerisce che ogni suggerimento di revisione che non è
0085 presente nella modifica del codice dovrebbe essere inserito in un commento
0086 aggiuntivo; ciò può essere d'aiuto ai futuri revisori nell'evitare domande
0087 che sorgono al primo sguardo.
0088
0089 Un errore fatale è quello di ignorare i commenti di revisione nella speranza
0090 che se ne andranno. Non andranno via. Se pubblicherete nuovamente il
0091 codice senza aver risposto ai commenti ricevuti, probabilmente le vostre
0092 modifiche non andranno da nessuna parte.
0093
0094 Parlando di ripubblicazione del codice: per favore tenete a mente che i
0095 revisori non ricorderanno tutti i dettagli del codice che avete pubblicato
0096 l'ultima volta. Quindi è sempre una buona idea quella di ricordare ai
0097 revisori le questioni sollevate precedetemene e come le avete risolte.
0098 I revisori non dovrebbero star lì a cercare all'interno degli archivi per
0099 famigliarizzare con ciò che è stato detto l'ultima volta; se li aiutate
0100 in questo senso, saranno di umore migliore quando riguarderanno il vostro
0101 codice.
0102
0103 Se invece avete cercato di far tutto correttamente ma le cose continuano
0104 a non andar bene? Molti disaccordi di natura tecnica possono essere risolti
0105 attraverso la discussione, ma ci sono volte dove qualcuno deve prendere
0106 una decisione. Se credete veramente che tale decisione andrà contro di voi
0107 ingiustamente, potete sempre tentare di rivolgervi a qualcuno più
0108 in alto di voi. Per cose di questo genere la persona con più potere è
0109 Andrew Morton. Andrew è una figura molto rispettata all'interno della
0110 comunità di sviluppo del kernel; lui può spesso sbrogliare situazioni che
0111 sembrano irrimediabilmente bloccate. Rivolgersi ad Andrew non deve essere
0112 fatto alla leggera, e non deve essere fatto prima di aver esplorato tutte
0113 le altre alternative. E tenete a mente, ovviamente, che nemmeno lui
0114 potrebbe non essere d'accordo con voi.
0115
0116 Cosa accade poi
0117 ===============
0118
0119 Se la modifica è ritenuta un elemento valido da essere aggiunta al kernel,
0120 e una volta che la maggior parte degli appunti dei revisori sono stati
0121 sistemati, il passo successivo solitamente è quello di entrare in un
0122 sottosistema gestito da un manutentore. Come ciò avviene dipende dal
0123 sottosistema medesimo; ogni manutentore ha il proprio modo di fare le cose.
0124 In particolare, ci potrebbero essere diversi sorgenti - uno, magari, dedicato
0125 alle modifiche pianificate per la finestra di fusione successiva, e un altro
0126 per il lavoro di lungo periodo.
0127
0128 Per le modifiche proposte in aree per le quali non esiste un sottosistema
0129 preciso (modifiche di gestione della memoria, per esempio), i sorgenti di
0130 ripiego finiscono per essere -mm. Ed anche le modifiche che riguardano
0131 più sottosistemi possono finire in quest'ultimo.
0132
0133 L'inclusione nei sorgenti di un sottosistema può comportare per una patch,
0134 un alto livello di visibilità. Ora altri sviluppatori che stanno lavorando
0135 in quei medesimi sorgenti avranno le vostre modifiche. I sottosistemi
0136 solitamente riforniscono anche Linux-next, rendendo i propri contenuti
0137 visibili all'intera comunità di sviluppo. A questo punto, ci sono buone
0138 possibilità per voi di ricevere ulteriori commenti da un nuovo gruppo di
0139 revisori; anche a questi commenti dovrete rispondere come avete già fatto per
0140 gli altri.
0141
0142 Ciò che potrebbe accadere a questo punto, in base alla natura della vostra
0143 modifica, riguarda eventuali conflitti con il lavoro svolto da altri.
0144 Nella peggiore delle situazioni, i conflitti più pesanti tra modifiche possono
0145 concludersi con la messa a lato di alcuni dei lavori svolti cosicché le
0146 modifiche restanti possano funzionare ed essere integrate. Altre volte, la
0147 risoluzione dei conflitti richiederà del lavoro con altri sviluppatori e,
0148 possibilmente, lo spostamento di alcune patch da dei sorgenti a degli altri
0149 in modo da assicurare che tutto sia applicato in modo pulito. Questo lavoro
0150 può rivelarsi una spina nel fianco, ma consideratevi fortunati: prima
0151 dell'avvento dei sorgenti linux-next, questi conflitti spesso emergevano solo
0152 durante l'apertura della finestra di integrazione e dovevano essere smaltiti
0153 in fretta. Ora essi possono essere risolti comodamente, prima dell'apertura
0154 della finestra.
0155
0156 Un giorno, se tutto va bene, vi collegherete e vedrete che la vostra patch
0157 è stata inserita nel ramo principale de kernel. Congratulazioni! Terminati
0158 i festeggiamenti (nel frattempo avrete inserito il vostro nome nel file
0159 MAINTAINERS) vale la pena ricordare una piccola cosa, ma importante: il
0160 lavoro non è ancora finito. L'inserimento nel ramo principale porta con se
0161 nuove sfide.
0162
0163 Cominciamo con il dire che ora la visibilità della vostra modifica è
0164 ulteriormente cresciuta. Ci potrebbe portare ad una nuova fase di
0165 commenti dagli sviluppatori che non erano ancora a conoscenza della vostra
0166 patch. Ignorarli potrebbe essere allettante dato che non ci sono più
0167 dubbi sull'integrazione della modifica. Resistete a tale tentazione, dovete
0168 mantenervi disponibili agli sviluppatori che hanno domande o suggerimenti
0169 per voi.
0170
0171 Ancora più importante: l'inclusione nel ramo principale mette il vostro
0172 codice nelle mani di un gruppo di *tester* molto più esteso. Anche se avete
0173 contribuito ad un driver per un hardware che non è ancora disponibile, sarete
0174 sorpresi da quante persone inseriranno il vostro codice nei loro kernel.
0175 E, ovviamente, dove ci sono *tester*, ci saranno anche dei rapporti su
0176 eventuali bachi.
0177
0178 La peggior specie di rapporti sono quelli che indicano delle regressioni.
0179 Se la vostra modifica causa una regressione, avrete un gran numero di
0180 occhi puntati su di voi; la regressione deve essere sistemata il prima
0181 possibile. Se non vorrete o non sarete capaci di sistemarla (e nessuno
0182 lo farà per voi), la vostra modifica sarà quasi certamente rimossa durante
0183 la fase di stabilizzazione. Oltre alla perdita di tutto il lavoro svolto
0184 per far si che la vostra modifica fosse inserita nel ramo principale,
0185 l'avere una modifica rimossa a causa del fallimento nel sistemare una
0186 regressione, potrebbe rendere più difficile per voi far accettare
0187 il vostro lavoro in futuro.
0188
0189 Dopo che ogni regressione è stata affrontata, ci potrebbero essere altri
0190 bachi ordinari da "sconfiggere". Il periodo di stabilizzazione è la
0191 vostra migliore opportunità per sistemare questi bachi e assicurarvi che
0192 il debutto del vostro codice nel ramo principale del kernel sia il più solido
0193 possibile. Quindi, per favore, rispondete ai rapporti sui bachi e ponete
0194 rimedio, se possibile, a tutti i problemi. È a questo che serve il periodo
0195 di stabilizzazione; potete iniziare creando nuove fantastiche modifiche
0196 una volta che ogni problema con le vecchie sia stato risolto.
0197
0198 Non dimenticate che esistono altre pietre miliari che possono generare
0199 rapporti sui bachi: il successivo rilascio stabile, quando una distribuzione
0200 importante usa una versione del kernel nel quale è presente la vostra
0201 modifica, eccetera. Il continuare a rispondere a questi rapporti è fonte di
0202 orgoglio per il vostro lavoro. Se questa non è una sufficiente motivazione,
0203 allora, è anche consigliabile considera che la comunità di sviluppo ricorda
0204 gli sviluppatori che hanno perso interesse per il loro codice una volta
0205 integrato. La prossima volta che pubblicherete una patch, la comunità
0206 la valuterà anche sulla base del fatto che non sarete disponibili a
0207 prendervene cura anche nel futuro.
0208
0209
0210 Altre cose che posso accadere
0211 =============================
0212
0213 Un giorno, potreste aprire la vostra email e vedere che qualcuno vi ha
0214 inviato una patch per il vostro codice. Questo, dopo tutto, è uno dei
0215 vantaggi di avere il vostro codice "là fuori". Se siete d'accordo con
0216 la modifica, potrete anche inoltrarla ad un manutentore di sottosistema
0217 (assicuratevi di includere la riga "From:" cosicché l'attribuzione sia
0218 corretta, e aggiungete una vostra firma "Signed-off-by"), oppure inviate
0219 un "Acked-by:" e lasciate che l'autore originale la invii.
0220
0221 Se non siete d'accordo con la patch, inviate una risposta educata
0222 spiegando il perché. Se possibile, dite all'autore quali cambiamenti
0223 servirebbero per rendere la patch accettabile da voi. C'è una certa
0224 riluttanza nell'inserire modifiche con un conflitto fra autore
0225 e manutentore del codice, ma solo fino ad un certo punto. Se siete visti
0226 come qualcuno che blocca un buon lavoro senza motivo, quelle patch vi
0227 passeranno oltre e andranno nel ramo principale in ogni caso. Nel kernel
0228 Linux, nessuno ha potere di veto assoluto su alcun codice. Eccezione
0229 fatta per Linus, forse.
0230
0231 In rarissime occasioni, potreste vedere qualcosa di completamente diverso:
0232 un altro sviluppatore che pubblica una soluzione differente al vostro
0233 problema. A questo punto, c'è una buona probabilità che una delle due
0234 modifiche non verrà integrata, e il "c'ero prima io" non è considerato
0235 un argomento tecnico rilevante. Se la modifica di qualcun'altro rimpiazza
0236 la vostra ed entra nel ramo principale, esiste un unico modo di reagire:
0237 siate contenti che il vostro problema sia stato risolto e andate avanti con
0238 il vostro lavoro. L'avere un vostro lavoro spintonato da parte in questo
0239 modo può essere avvilente e scoraggiante, ma la comunità ricorderà come
0240 avrete reagito anche dopo che avrà dimenticato quale fu la modifica accettata.
