Lines Matching full:se
36 resa molto più facile se tenete presente alcuni dettagli:
38 - Se avete descritto la vostra modifica correttamente, i revisori ne
51 fatti ancora e ancora. Se ricevete una revisione che vi sembra abbia
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.
90 che se ne andranno. Non andranno via. Se pubblicherete nuovamente il
99 famigliarizzare con ciò che è stato detto l'ultima volta; se li aiutate
103 Se invece avete cercato di far tutto correttamente ma le cose continuano
106 una decisione. Se credete veramente che tale decisione andrà contro di voi
119 Se la modifica è ritenuta un elemento valido da essere aggiunta al kernel,
156 Un giorno, se tutto va bene, vi collegherete e vedrete che la vostra patch
160 lavoro non è ancora finito. L'inserimento nel ramo principale porta con se
172 codice nelle mani di un gruppo di *tester* molto più esteso. Anche se avete
179 Se la vostra modifica causa una regressione, avrete un gran numero di
181 possibile. Se non vorrete o non sarete capaci di sistemarla (e nessuno
194 rimedio, se possibile, a tutti i problemi. È a questo che serve il periodo
202 orgoglio per il vostro lavoro. Se questa non è una sufficiente motivazione,
215 vantaggi di avere il vostro codice "là fuori". Se siete d'accordo con
221 Se non siete d'accordo con la patch, inviate una risposta educata
222 spiegando il perché. Se possibile, dite all'autore quali cambiamenti
225 e manutentore del codice, ma solo fino ad un certo punto. Se siete visti
235 un argomento tecnico rilevante. Se la modifica di qualcun'altro rimpiazza