Lines Matching full:per

24 lavorare con la comunità del kernel per assicurare che il vostro codice
34 Lavorare con i revisori può rivelarsi, per molti sviluppatori, la parte
45 continuo sviluppo ancora per diverse decadi.
58 aspettano di lavorare sul kernel per anni, ma sanno che il loro datore
60 stanno lavorando per la creazione del miglior kernel possibile; non
67 nel vostro driver per aggirare un problema deve diventare una caratteristica
68 generalizzata del kernel pronta per essere riutilizzata.
74 prendetevi il tempo per comprendere cosa il revisore stia cercando di
79 Notate che non dovete per forza essere d'accordo con ogni singola modifica
86 Prendetevi quindi un po' di tempo per pensare ancora alla cosa. Può risultare
101 Parlando di ripubblicazione del codice: per favore tenete a mente che i
105 I revisori non dovrebbero star lì a cercare all'interno degli archivi per
115 in alto di voi. Per cose di questo genere la persona con più potere è
132 alle modifiche pianificate per la finestra di fusione successiva, e un altro
133 per il lavoro di lungo periodo.
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
140 L'inclusione nei sorgenti di un sottosistema può comportare per una patch,
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
176 per voi.
180 contribuito ad un driver per un hardware che non è ancora disponibile, sarete
189 lo farà per voi), la vostra modifica sarà quasi certamente rimossa durante
191 per far si che la vostra modifica fosse inserita nel ramo principale,
193 regressione, potrebbe rendere più difficile per voi far accettare
198 vostra migliore opportunità per sistemare questi bachi e assicurarvi che
200 possibile. Quindi, per favore, rispondete ai rapporti sui bachi e ponete
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
230 servirebbero per rendere la patch accettabile da voi. C'è una certa
236 fatta per Linus, forse.