248 lines · plain
1.. include:: ../disclaimer-ita.rst2 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=============9Completamento10=============11 12A questo punto, avete seguito le linee guida fino a questo punto e, con13l'aggiunta delle vostre capacità ingegneristiche, avete pubblicato una serie14perfetta di patch. Uno dei più grandi errori che possono essere commessi15persino da sviluppatori kernel esperti è quello di concludere che il16lavoro sia ormai finito. In verità, la pubblicazione delle patch17simboleggia una transizione alla fase successiva del processo, con,18probabilmente, ancora un po' di lavoro da fare.19 20È raro che una modifica sia così bella alla sua prima pubblicazione che non21ci sia alcuno spazio di miglioramento. Il programma di sviluppo del kernel22riconosce questo fatto e quindi, è fortemente orientato al miglioramento23del codice pubblicato. Voi, in qualità di autori del codice, dovrete24lavorare con la comunità del kernel per assicurare che il vostro codice25mantenga gli standard qualitativi richiesti. Un fallimento in questo26processo è quasi come impedire l'inclusione delle vostre patch nel27ramo principale.28 29Lavorare con i revisori30=======================31 32Una patch che abbia una certa rilevanza avrà ricevuto numerosi commenti33da parte di altri sviluppatori dato che avranno revisionato il codice.34Lavorare con i revisori può rivelarsi, per molti sviluppatori, la parte35più intimidatoria del processo di sviluppo del kernel. La vita può esservi36resa molto più facile se tenete presente alcuni dettagli:37 38 - Se avete descritto la vostra modifica correttamente, i revisori ne39 comprenderanno il valore e il perché vi siete presi il disturbo di40 scriverla. Ma tale valore non li tratterrà dal porvi una domanda41 fondamentale: come verrà mantenuto questo codice nel kernel nei prossimi42 cinque o dieci anni? Molti dei cambiamenti che potrebbero esservi43 richiesti - da piccoli problemi di stile a sostanziali ristesure -44 vengono dalla consapevolezza che Linux resterà in circolazione e in45 continuo sviluppo ancora per diverse decadi.46 47 - La revisione del codice è un duro lavoro, ed è un mestiere poco48 riconosciuto; le persone ricordano chi ha scritto il codice, ma meno49 fama è attribuita a chi lo ha revisionato. Quindi i revisori potrebbero50 divenire burberi, specialmente quando vendono i medesimi errori venire51 fatti ancora e ancora. Se ricevete una revisione che vi sembra abbia52 un tono arrabbiato, insultante o addirittura offensivo, resistente alla53 tentazione di rispondere a tono. La revisione riguarda il codice e non54 la persona, e i revisori non vi stanno attaccando personalmente.55 56 - Similarmente, i revisori del codice non stanno cercando di promuovere57 i loro interessi a vostre spese. Gli sviluppatori del kernel spesso si58 aspettano di lavorare sul kernel per anni, ma sanno che il loro datore59 di lavoro può cambiare. Davvero, senza praticamente eccezioni, loro60 stanno lavorando per la creazione del miglior kernel possibile; non61 stanno cercando di creare un disagio ad aziende concorrenti.62 63 - Preparatevi a richieste apparentemente sciocche di modifiche allo stile di64 codifica e a richieste di trasferire parte del vostro codice in parti65 condivise del kernel. Uno dei compiti dei manutentori è quello di mantenere66 lo aspetto del codice. A volte questo significa che l'ingegnoso stratagemma67 nel vostro driver per aggirare un problema deve diventare una caratteristica68 generalizzata del kernel pronta per essere riutilizzata.69 70Quello che si sta cercando di dire è che, quando i revisori vi inviano degli71appunti dovete fare attenzione alle osservazioni tecniche che vi stanno72facendo. Non lasciate che il loro modo di esprimersi o il vostro orgoglio73impediscano che ciò accada. Quando avete dei suggerimenti sulla revisione,74prendetevi il tempo per comprendere cosa il revisore stia cercando di75comunicarvi. Se possibile, sistemate le cose che il revisore vi chiede di76modificare. E rispondete al revisore ringraziandolo e spiegando come77intendete fare.78 79Notate che non dovete per forza essere d'accordo con ogni singola modifica80suggerita dai revisori. Se credete che il revisore non abbia compreso81il vostro codice, spiegateglielo. Se avete un'obiezione tecnica da fargli82su di una modifica suggerita, spiegatela inserendo anche la vostra soluzione83al problema. Se la vostra spiegazione ha senso, il revisore la accetterà.84Tuttavia, la vostra motivazione potrebbe non essere del tutto persuasiva,85specialmente se altri iniziano ad essere d'accordo con il revisore.86Prendetevi quindi un po' di tempo per pensare ancora alla cosa. Può risultare87facile essere accecati dalla propria soluzione al punto che non realizzate che88c'è qualcosa di fondamentalmente sbagliato o, magari, non state nemmeno89risolvendo il problema giusto.90 91Andrew Morton suggerisce che ogni suggerimento di revisione che non è92presente nella modifica del codice dovrebbe essere inserito in un commento93aggiuntivo; ciò può essere d'aiuto ai futuri revisori nell'evitare domande94che sorgono al primo sguardo.95 96Un errore fatale è quello di ignorare i commenti di revisione nella speranza97che se ne andranno. Non andranno via. Se pubblicherete nuovamente il98codice senza aver risposto ai commenti ricevuti, probabilmente le vostre99modifiche non andranno da nessuna parte.100 101Parlando di ripubblicazione del codice: per favore tenete a mente che i102revisori non ricorderanno tutti i dettagli del codice che avete pubblicato103l'ultima volta. Quindi è sempre una buona idea quella di ricordare ai104revisori le questioni sollevate precedetemene e come le avete risolte.105I revisori non dovrebbero star lì a cercare all'interno degli archivi per106famigliarizzare con ciò che è stato detto l'ultima volta; se li aiutate107in questo senso, saranno di umore migliore quando riguarderanno il vostro108codice.109 110Se invece avete cercato di far tutto correttamente ma le cose continuano111a non andar bene? Molti disaccordi di natura tecnica possono essere risolti112attraverso la discussione, ma ci sono volte dove qualcuno deve prendere113una decisione. Se credete veramente che tale decisione andrà contro di voi114ingiustamente, potete sempre tentare di rivolgervi a qualcuno più115in alto di voi. Per cose di questo genere la persona con più potere è116Andrew Morton. Andrew è una figura molto rispettata all'interno della117comunità di sviluppo del kernel; lui può spesso sbrogliare situazioni che118sembrano irrimediabilmente bloccate. Rivolgersi ad Andrew non deve essere119fatto alla leggera, e non deve essere fatto prima di aver esplorato tutte120le altre alternative. E tenete a mente, ovviamente, che nemmeno lui121potrebbe non essere d'accordo con voi.122 123Cosa accade poi124===============125 126Se la modifica è ritenuta un elemento valido da essere aggiunta al kernel,127e una volta che la maggior parte degli appunti dei revisori sono stati128sistemati, il passo successivo solitamente è quello di entrare in un129sottosistema gestito da un manutentore. Come ciò avviene dipende dal130sottosistema medesimo; ogni manutentore ha il proprio modo di fare le cose.131In particolare, ci potrebbero essere diversi sorgenti - uno, magari, dedicato132alle modifiche pianificate per la finestra di fusione successiva, e un altro133per il lavoro di lungo periodo.134 135Per le modifiche proposte in aree per le quali non esiste un sottosistema136preciso (modifiche di gestione della memoria, per esempio), i sorgenti di137ripiego finiscono per essere -mm. Ed anche le modifiche che riguardano138più sottosistemi possono finire in quest'ultimo.139 140L'inclusione nei sorgenti di un sottosistema può comportare per una patch,141un alto livello di visibilità. Ora altri sviluppatori che stanno lavorando142in quei medesimi sorgenti avranno le vostre modifiche. I sottosistemi143solitamente riforniscono anche Linux-next, rendendo i propri contenuti144visibili all'intera comunità di sviluppo. A questo punto, ci sono buone145possibilità per voi di ricevere ulteriori commenti da un nuovo gruppo di146revisori; anche a questi commenti dovrete rispondere come avete già fatto per147gli altri.148 149Ciò che potrebbe accadere a questo punto, in base alla natura della vostra150modifica, riguarda eventuali conflitti con il lavoro svolto da altri.151Nella peggiore delle situazioni, i conflitti più pesanti tra modifiche possono152concludersi con la messa a lato di alcuni dei lavori svolti cosicché le153modifiche restanti possano funzionare ed essere integrate. Altre volte, la154risoluzione dei conflitti richiederà del lavoro con altri sviluppatori e,155possibilmente, lo spostamento di alcune patch da dei sorgenti a degli altri156in modo da assicurare che tutto sia applicato in modo pulito. Questo lavoro157può rivelarsi una spina nel fianco, ma consideratevi fortunati: prima158dell'avvento dei sorgenti linux-next, questi conflitti spesso emergevano solo159durante l'apertura della finestra di integrazione e dovevano essere smaltiti160in fretta. Ora essi possono essere risolti comodamente, prima dell'apertura161della finestra.162 163Un giorno, se tutto va bene, vi collegherete e vedrete che la vostra patch164è stata inserita nel ramo principale de kernel. Congratulazioni! Terminati165i festeggiamenti (nel frattempo avrete inserito il vostro nome nel file166MAINTAINERS) vale la pena ricordare una piccola cosa, ma importante: il167lavoro non è ancora finito. L'inserimento nel ramo principale porta con se168nuove sfide.169 170Cominciamo con il dire che ora la visibilità della vostra modifica è171ulteriormente cresciuta. Ci potrebbe portare ad una nuova fase di172commenti dagli sviluppatori che non erano ancora a conoscenza della vostra173patch. Ignorarli potrebbe essere allettante dato che non ci sono più174dubbi sull'integrazione della modifica. Resistete a tale tentazione, dovete175mantenervi disponibili agli sviluppatori che hanno domande o suggerimenti176per voi.177 178Ancora più importante: l'inclusione nel ramo principale mette il vostro179codice nelle mani di un gruppo di *tester* molto più esteso. Anche se avete180contribuito ad un driver per un hardware che non è ancora disponibile, sarete181sorpresi da quante persone inseriranno il vostro codice nei loro kernel.182E, ovviamente, dove ci sono *tester*, ci saranno anche dei rapporti su183eventuali bachi.184 185La peggior specie di rapporti sono quelli che indicano delle regressioni.186Se la vostra modifica causa una regressione, avrete un gran numero di187occhi puntati su di voi; la regressione deve essere sistemata il prima188possibile. Se non vorrete o non sarete capaci di sistemarla (e nessuno189lo farà per voi), la vostra modifica sarà quasi certamente rimossa durante190la fase di stabilizzazione. Oltre alla perdita di tutto il lavoro svolto191per far si che la vostra modifica fosse inserita nel ramo principale,192l'avere una modifica rimossa a causa del fallimento nel sistemare una193regressione, potrebbe rendere più difficile per voi far accettare194il vostro lavoro in futuro.195 196Dopo che ogni regressione è stata affrontata, ci potrebbero essere altri197bachi ordinari da "sconfiggere". Il periodo di stabilizzazione è la198vostra migliore opportunità per sistemare questi bachi e assicurarvi che199il debutto del vostro codice nel ramo principale del kernel sia il più solido200possibile. Quindi, per favore, rispondete ai rapporti sui bachi e ponete201rimedio, se possibile, a tutti i problemi. È a questo che serve il periodo202di stabilizzazione; potete iniziare creando nuove fantastiche modifiche203una volta che ogni problema con le vecchie sia stato risolto.204 205Non dimenticate che esistono altre pietre miliari che possono generare206rapporti sui bachi: il successivo rilascio stabile, quando una distribuzione207importante usa una versione del kernel nel quale è presente la vostra208modifica, eccetera. Il continuare a rispondere a questi rapporti è fonte di209orgoglio per il vostro lavoro. Se questa non è una sufficiente motivazione,210allora, è anche consigliabile considera che la comunità di sviluppo ricorda211gli sviluppatori che hanno perso interesse per il loro codice una volta212integrato. La prossima volta che pubblicherete una patch, la comunità213la valuterà anche sulla base del fatto che non sarete disponibili a214prendervene cura anche nel futuro.215 216 217Altre cose che posso accadere218=============================219 220Un giorno, potreste aprire la vostra email e vedere che qualcuno vi ha221inviato una patch per il vostro codice. Questo, dopo tutto, è uno dei222vantaggi di avere il vostro codice "là fuori". Se siete d'accordo con223la modifica, potrete anche inoltrarla ad un manutentore di sottosistema224(assicuratevi di includere la riga "From:" cosicché l'attribuzione sia225corretta, e aggiungete una vostra firma "Signed-off-by"), oppure inviate226un "Acked-by:" e lasciate che l'autore originale la invii.227 228Se non siete d'accordo con la patch, inviate una risposta educata229spiegando il perché. Se possibile, dite all'autore quali cambiamenti230servirebbero per rendere la patch accettabile da voi. C'è una certa231riluttanza nell'inserire modifiche con un conflitto fra autore232e manutentore del codice, ma solo fino ad un certo punto. Se siete visti233come qualcuno che blocca un buon lavoro senza motivo, quelle patch vi234passeranno oltre e andranno nel ramo principale in ogni caso. Nel kernel235Linux, nessuno ha potere di veto assoluto su alcun codice. Eccezione236fatta per Linus, forse.237 238In rarissime occasioni, potreste vedere qualcosa di completamente diverso:239un altro sviluppatore che pubblica una soluzione differente al vostro240problema. A questo punto, c'è una buona probabilità che una delle due241modifiche non verrà integrata, e il "c'ero prima io" non è considerato242un argomento tecnico rilevante. Se la modifica di qualcun'altro rimpiazza243la vostra ed entra nel ramo principale, esiste un unico modo di reagire:244siate contenti che il vostro problema sia stato risolto e andate avanti con245il vostro lavoro. L'avere un vostro lavoro spintonato da parte in questo246modo può essere avvilente e scoraggiante, ma la comunità ricorderà come247avrete reagito anche dopo che avrà dimenticato quale fu la modifica accettata.248