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 - Preparatevi a richieste apparentemente sciocche di modifiche allo stile di 64 codifica e a richieste di trasferire parte del vostro codice in parti 65 condivise del kernel. Uno dei compiti dei manutentori è quello di mantenere 66 lo aspetto del codice. A volte questo significa che l'ingegnoso stratagemma 67 nel vostro driver per aggirare un problema deve diventare una caratteristica 68 generalizzata del kernel pronta per essere riutilizzata. 69 70 Quello che si sta cercando di dire è che, quando i revisori vi inviano degli 71 appunti dovete fare attenzione alle osservazioni tecniche che vi stanno 72 facendo. Non lasciate che il loro modo di esprimersi o il vostro orgoglio 73 impediscano che ciò accada. Quando avete dei suggerimenti sulla revisione, 74 prendetevi il tempo per comprendere cosa il revisore stia cercando di 75 comunicarvi. Se possibile, sistemate le cose che il revisore vi chiede di 76 modificare. E rispondete al revisore ringraziandolo e spiegando come 77 intendete fare. 78 79 Notate che non dovete per forza essere d'accordo con ogni singola modifica 80 suggerita dai revisori. Se credete che il revisore non abbia compreso 81 il vostro codice, spiegateglielo. Se avete un'obiezione tecnica da fargli 82 su di una modifica suggerita, spiegatela inserendo anche la vostra soluzione 83 al problema. Se la vostra spiegazione ha senso, il revisore la accetterà. 84 Tuttavia, la vostra motivazione potrebbe non essere del tutto persuasiva, 85 specialmente se altri iniziano ad essere d'accordo con il revisore. 86 Prendetevi quindi un po' di tempo per pensare ancora alla cosa. Può risultare 87 facile essere accecati dalla propria soluzione al punto che non realizzate che 88 c'è qualcosa di fondamentalmente sbagliato o, magari, non state nemmeno 89 risolvendo il problema giusto. 90 91 Andrew Morton suggerisce che ogni suggerimento di revisione che non è 92 presente nella modifica del codice dovrebbe essere inserito in un commento 93 aggiuntivo; ciò può essere d'aiuto ai futuri revisori nell'evitare domande 94 che sorgono al primo sguardo. 95 96 Un errore fatale è quello di ignorare i commenti di revisione nella speranza 97 che se ne andranno. Non andranno via. Se pubblicherete nuovamente il 98 codice senza aver risposto ai commenti ricevuti, probabilmente le vostre 99 modifiche non andranno da nessuna parte. 100 101 Parlando di ripubblicazione del codice: per favore tenete a mente che i 102 revisori non ricorderanno tutti i dettagli del codice che avete pubblicato 103 l'ultima volta. Quindi è sempre una buona idea quella di ricordare ai 104 revisori le questioni sollevate precedetemene e come le avete risolte. 105 I revisori non dovrebbero star lì a cercare all'interno degli archivi per 106 famigliarizzare con ciò che è stato detto l'ultima volta; se li aiutate 107 in questo senso, saranno di umore migliore quando riguarderanno il vostro 108 codice. 109 110 Se invece avete cercato di far tutto correttamente ma le cose continuano 111 a non andar bene? Molti disaccordi di natura tecnica possono essere risolti 112 attraverso la discussione, ma ci sono volte dove qualcuno deve prendere 113 una decisione. Se credete veramente che tale decisione andrà contro di voi 114 ingiustamente, potete sempre tentare di rivolgervi a qualcuno più 115 in alto di voi. Per cose di questo genere la persona con più potere è 116 Andrew Morton. Andrew è una figura molto rispettata all'interno della 117 comunità di sviluppo del kernel; lui può spesso sbrogliare situazioni che 118 sembrano irrimediabilmente bloccate. Rivolgersi ad Andrew non deve essere 119 fatto alla leggera, e non deve essere fatto prima di aver esplorato tutte 120 le altre alternative. E tenete a mente, ovviamente, che nemmeno lui 121 potrebbe non essere d'accordo con voi. 122 123 Cosa accade poi 124 =============== 125 126 Se la modifica è ritenuta un elemento valido da essere aggiunta al kernel, 127 e una volta che la maggior parte degli appunti dei revisori sono stati 128 sistemati, il passo successivo solitamente è quello di entrare in un 129 sottosistema gestito da un manutentore. Come ciò avviene dipende dal 130 sottosistema medesimo; ogni manutentore ha il proprio modo di fare le cose. 131 In particolare, ci potrebbero essere diversi sorgenti - uno, magari, dedicato 132 alle modifiche pianificate per la finestra di fusione successiva, e un altro 133 per il lavoro di lungo periodo. 134 135 Per le modifiche proposte in aree per le quali non esiste un sottosistema 136 preciso (modifiche di gestione della memoria, per esempio), i sorgenti di 137 ripiego finiscono per essere -mm. Ed anche le modifiche che riguardano 138 più sottosistemi possono finire in quest'ultimo. 139 140 L'inclusione nei sorgenti di un sottosistema può comportare per una patch, 141 un alto livello di visibilità. Ora altri sviluppatori che stanno lavorando 142 in quei medesimi sorgenti avranno le vostre modifiche. I sottosistemi 143 solitamente riforniscono anche Linux-next, rendendo i propri contenuti 144 visibili all'intera comunità di sviluppo. A questo punto, ci sono buone 145 possibilità per voi di ricevere ulteriori commenti da un nuovo gruppo di 146 revisori; anche a questi commenti dovrete rispondere come avete già fatto per 147 gli altri. 148 149 Ciò che potrebbe accadere a questo punto, in base alla natura della vostra 150 modifica, riguarda eventuali conflitti con il lavoro svolto da altri. 151 Nella peggiore delle situazioni, i conflitti più pesanti tra modifiche possono 152 concludersi con la messa a lato di alcuni dei lavori svolti cosicché le 153 modifiche restanti possano funzionare ed essere integrate. Altre volte, la 154 risoluzione dei conflitti richiederà del lavoro con altri sviluppatori e, 155 possibilmente, lo spostamento di alcune patch da dei sorgenti a degli altri 156 in modo da assicurare che tutto sia applicato in modo pulito. Questo lavoro 157 può rivelarsi una spina nel fianco, ma consideratevi fortunati: prima 158 dell'avvento dei sorgenti linux-next, questi conflitti spesso emergevano solo 159 durante l'apertura della finestra di integrazione e dovevano essere smaltiti 160 in fretta. Ora essi possono essere risolti comodamente, prima dell'apertura 161 della finestra. 162 163 Un giorno, se tutto va bene, vi collegherete e vedrete che la vostra patch 164 è stata inserita nel ramo principale de kernel. Congratulazioni! Terminati 165 i festeggiamenti (nel frattempo avrete inserito il vostro nome nel file 166 MAINTAINERS) vale la pena ricordare una piccola cosa, ma importante: il 167 lavoro non è ancora finito. L'inserimento nel ramo principale porta con se 168 nuove sfide. 169 170 Cominciamo con il dire che ora la visibilità della vostra modifica è 171 ulteriormente cresciuta. Ci potrebbe portare ad una nuova fase di 172 commenti dagli sviluppatori che non erano ancora a conoscenza della vostra 173 patch. Ignorarli potrebbe essere allettante dato che non ci sono più 174 dubbi sull'integrazione della modifica. Resistete a tale tentazione, dovete 175 mantenervi disponibili agli sviluppatori che hanno domande o suggerimenti 176 per voi. 177 178 Ancora più importante: l'inclusione nel ramo principale mette il vostro 179 codice nelle mani di un gruppo di *tester* molto più esteso. Anche se avete 180 contribuito ad un driver per un hardware che non è ancora disponibile, sarete 181 sorpresi da quante persone inseriranno il vostro codice nei loro kernel. 182 E, ovviamente, dove ci sono *tester*, ci saranno anche dei rapporti su 183 eventuali bachi. 184 185 La peggior specie di rapporti sono quelli che indicano delle regressioni. 186 Se la vostra modifica causa una regressione, avrete un gran numero di 187 occhi puntati su di voi; la regressione deve essere sistemata il prima 188 possibile. Se non vorrete o non sarete capaci di sistemarla (e nessuno 189 lo farà per voi), la vostra modifica sarà quasi certamente rimossa durante 190 la fase di stabilizzazione. Oltre alla perdita di tutto il lavoro svolto 191 per far si che la vostra modifica fosse inserita nel ramo principale, 192 l'avere una modifica rimossa a causa del fallimento nel sistemare una 193 regressione, potrebbe rendere più difficile per voi far accettare 194 il vostro lavoro in futuro. 195 196 Dopo che ogni regressione è stata affrontata, ci potrebbero essere altri 197 bachi ordinari da "sconfiggere". Il periodo di stabilizzazione è la 198 vostra migliore opportunità per sistemare questi bachi e assicurarvi che 199 il debutto del vostro codice nel ramo principale del kernel sia il più solido 200 possibile. Quindi, per favore, rispondete ai rapporti sui bachi e ponete 201 rimedio, se possibile, a tutti i problemi. È a questo che serve il periodo 202 di stabilizzazione; potete iniziare creando nuove fantastiche modifiche 203 una volta che ogni problema con le vecchie sia stato risolto. 204 205 Non dimenticate che esistono altre pietre miliari che possono generare 206 rapporti sui bachi: il successivo rilascio stabile, quando una distribuzione 207 importante usa una versione del kernel nel quale è presente la vostra 208 modifica, eccetera. Il continuare a rispondere a questi rapporti è fonte di 209 orgoglio per il vostro lavoro. Se questa non è una sufficiente motivazione, 210 allora, è anche consigliabile considera che la comunità di sviluppo ricorda 211 gli sviluppatori che hanno perso interesse per il loro codice una volta 212 integrato. La prossima volta che pubblicherete una patch, la comunità 213 la valuterà anche sulla base del fatto che non sarete disponibili a 214 prendervene cura anche nel futuro. 215 216 217 Altre cose che posso accadere 218 ============================= 219 220 Un giorno, potreste aprire la vostra email e vedere che qualcuno vi ha 221 inviato una patch per il vostro codice. Questo, dopo tutto, è uno dei 222 vantaggi di avere il vostro codice "là fuori". Se siete d'accordo con 223 la modifica, potrete anche inoltrarla ad un manutentore di sottosistema 224 (assicuratevi di includere la riga "From:" cosicché l'attribuzione sia 225 corretta, e aggiungete una vostra firma "Signed-off-by"), oppure inviate 226 un "Acked-by:" e lasciate che l'autore originale la invii. 227 228 Se non siete d'accordo con la patch, inviate una risposta educata 229 spiegando il perché. Se possibile, dite all'autore quali cambiamenti 230 servirebbero per rendere la patch accettabile da voi. C'è una certa 231 riluttanza nell'inserire modifiche con un conflitto fra autore 232 e manutentore del codice, ma solo fino ad un certo punto. Se siete visti 233 come qualcuno che blocca un buon lavoro senza motivo, quelle patch vi 234 passeranno oltre e andranno nel ramo principale in ogni caso. Nel kernel 235 Linux, nessuno ha potere di veto assoluto su alcun codice. Eccezione 236 fatta per Linus, forse. 237 238 In rarissime occasioni, potreste vedere qualcosa di completamente diverso: 239 un altro sviluppatore che pubblica una soluzione differente al vostro 240 problema. A questo punto, c'è una buona probabilità che una delle due 241 modifiche non verrà integrata, e il "c'ero prima io" non è considerato 242 un argomento tecnico rilevante. Se la modifica di qualcun'altro rimpiazza 243 la vostra ed entra nel ramo principale, esiste un unico modo di reagire: 244 siate contenti che il vostro problema sia stato risolto e andate avanti con 245 il vostro lavoro. L'avere un vostro lavoro spintonato da parte in questo 246 modo può essere avvilente e scoraggiante, ma la comunità ricorderà come 247 avrete reagito anche dopo che avrà dimenticato quale fu la modifica accettata.
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.