Lines Matching refs:le
12 Esso contiene le istruzioni su come diventare uno sviluppatore
19 vi preghiamo di inviare le correzioni agli amministratori di questo
30 di spiegare alcune delle ragioni per le quali la comunità lavora in un
53 riguardo gli strumenti e le estensioni in uso, e sfortunatamente non
108 seguire le linee guida in questo documento. Molti amministratori
122 Seguire tali regole non garantirà il successo (tutte le patch sono soggette
145 dello sviluppo di Linux ed è molto importante per le persone che arrivano
162 Questo file descrive le regole sulle quali vengono basati i rilasci del
178 descrizione dell'API interna del kernel, e le regole su come gestire la
224 imparerete le basi per l'inserimento delle vostre modifiche all'interno dei
247 - Sorgenti dei sottosistemi del kernel e le loro modifiche
274 aggiunto. git può essere utilizzato per inviare le patch a Linus dopo che
275 la -rc1 è stata rilasciata, ma è anche necessario inviare le patch ad
316 Sorgenti dei sottosistemi del kernel e le loro patch
323 chiesto ad uno sviluppatore di basare le proprie modifiche su questi repositori
324 in modo da evitare i conflitti fra le sottomissioni ed altri lavori in corso
335 Patchwork offre un'interfaccia web che mostra le patch pubblicate, inclusi i
336 commenti o le revisioni fatte, e gli amministratori possono indicare le patch
375 Uno dei modi migliori per mettere in pratica le vostre capacità di hacking è
378 mondo ed accrescerete le vostre competenze, e gli altri sviluppatori saranno
428 Ricordate di rimanere sempre in argomento e di mantenere le attribuzioni
430 in cima alla vostra replica e aggiungete le vostre risposte fra i singoli
436 compresse; vogliono invece poter commentare le righe dei vostri cambiamenti,
460 all'interno del kernel. Dovete essere in grado di accettare le critiche,
461 valutarle a livello tecnico ed eventualmente rielaborare nuovamente le vostre
462 modifiche o fornire delle chiare e concise motivazioni per le quali le
465 qualche volta le cose si perdono nell'enorme mucchio di email.
482 È normale che le risposte alla vostra prima modifica possa essere
486 Semplicemente correggete tutte le questioni sollevate contro la vostra modifica
489 Differenze tra la comunità del kernel e le strutture aziendali
496 Cose da dire riguardanti le modifiche da voi proposte:
503 - "Questo aumenta le prestazioni di macchine standard..."
533 necessaria per esporre le proprie idee in maniera appropiata all'interno
534 delle liste di discussione, quindi è consigliabile che rileggiate le vostre
538 Spezzare le vostre modifiche
544 indipendenti. Questo è praticamente l'esatto opposto di quello che le
549 discarica per le vostre aggiunte. In ogni caso, non inviate 50 email nello
553 I motivi per i quali dovreste frammentare le cose sono i seguenti:
555 1) Piccole modifiche aumentano le probabilità che vengano accettate,
564 non va. È molto più facile annullare le modifiche una per una che
574 di uno studente (di matematica). L'insegnante non vuole vedere le
577 possibile. Un buono studente lo sa, e non presenterebbe mai le
588 revisione per migliorare il vostro lavoro, ma anche per riuscire a tenere le
596 Giustificare le vostre modifiche
604 Documentare le vostre modifiche
607 Quando inviate le vostre modifiche, fate particolare attenzione a quello che
640 David A. Wheeler, Junio Hamano, Michael Kerrisk, e Alex Shepard per le