it_IT/process/6.Followthrough.rst

15 persino da sviluppatori kernel esperti è quello di concludere che il
24 lavorare con la comunità del kernel per assicurare che il vostro codice
33 da parte di altri sviluppatori dato che avranno revisionato il codice.
39    comprenderanno il valore e il perché vi siete presi il disturbo di
48    riconosciuto; le persone ricordano chi ha scritto il codice, ma meno
53    tentazione di rispondere a tono.  La revisione riguarda il codice e non
58    aspettano di lavorare sul kernel per anni, ma sanno che il loro datore
72 facendo.  Non lasciate che il loro modo di esprimersi o il vostro orgoglio
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
80 suggerita dai revisori.  Se credete che il revisore non abbia compreso
81 il vostro codice, spiegateglielo.  Se avete un'obiezione tecnica da fargli
83 al problema.  Se la vostra spiegazione ha senso, il revisore la accetterà.
85 specialmente se altri iniziano ad essere d'accordo con il revisore.
89 risolvendo il problema giusto.
97 che se ne andranno.  Non andranno via.  Se pubblicherete nuovamente il
107 in questo senso, saranno di umore migliore quando riguarderanno il vostro
128 sistemati, il passo successivo solitamente è quello di entrare in un
130 sottosistema medesimo; ogni manutentore ha il proprio modo di fare le cose.
133 per il lavoro di lungo periodo.
150 modifica, riguarda eventuali conflitti con il lavoro svolto da altri.
165 i festeggiamenti (nel frattempo avrete inserito il vostro nome nel file
166 MAINTAINERS) vale la pena ricordare una piccola cosa, ma importante: il
170 Cominciamo con il dire che ora la visibilità della vostra modifica è
178 Ancora più importante: l'inclusione nel ramo principale mette il vostro
181 sorpresi da quante persone inseriranno il vostro codice nei loro kernel.
187 occhi puntati su di voi; la regressione deve essere sistemata il prima
190 la fase di stabilizzazione.  Oltre alla perdita di tutto il lavoro svolto
194 il vostro lavoro in futuro.
199 il debutto del vostro codice nel ramo principale del kernel sia il più solido
201 rimedio, se possibile, a tutti i problemi.  È a questo che serve il periodo
206 rapporti sui bachi: il successivo rilascio stabile, quando una distribuzione
209 orgoglio per il vostro lavoro.  Se questa non è una sufficiente motivazione,
211 gli sviluppatori che hanno perso interesse per il loro codice una volta
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
229 spiegando il perché.  Se possibile, dite all'autore quali cambiamenti
241 modifiche non verrà integrata, e il "c'ero prima io" non è considerato
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