Lines Matching refs:il
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
65 facendo. Non lasciate che il loro modo di esprimersi o il vostro orgoglio
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
73 suggerita dai revisori. Se credete che il revisore non abbia compreso
74 il vostro codice, spiegateglielo. Se avete un'obiezione tecnica da fargli
76 al problema. Se la vostra spiegazione ha senso, il revisore la accetterà.
78 specialmente se altri iniziano ad essere d'accordo con il revisore.
82 risolvendo il problema giusto.
90 che se ne andranno. Non andranno via. Se pubblicherete nuovamente il
100 in questo senso, saranno di umore migliore quando riguarderanno il vostro
121 sistemati, il passo successivo solitamente è quello di entrare in un
123 sottosistema medesimo; ogni manutentore ha il proprio modo di fare le cose.
126 per il lavoro di lungo periodo.
143 modifica, riguarda eventuali conflitti con il lavoro svolto da altri.
158 i festeggiamenti (nel frattempo avrete inserito il vostro nome nel file
159 MAINTAINERS) vale la pena ricordare una piccola cosa, ma importante: il
163 Cominciamo con il dire che ora la visibilità della vostra modifica è
171 Ancora più importante: l'inclusione nel ramo principale mette il vostro
174 sorpresi da quante persone inseriranno il vostro codice nei loro kernel.
180 occhi puntati su di voi; la regressione deve essere sistemata il prima
183 la fase di stabilizzazione. Oltre alla perdita di tutto il lavoro svolto
187 il vostro lavoro in futuro.
192 il debutto del vostro codice nel ramo principale del kernel sia il più solido
194 rimedio, se possibile, a tutti i problemi. È a questo che serve il periodo
199 rapporti sui bachi: il successivo rilascio stabile, quando una distribuzione
202 orgoglio per il vostro lavoro. Se questa non è una sufficiente motivazione,
204 gli sviluppatori che hanno perso interesse per il loro codice una volta
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
222 spiegando il perché. Se possibile, dite all'autore quali cambiamenti
234 modifiche non verrà integrata, e il "c'ero prima io" non è considerato
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