Lines Matching refs:nel
8 Inviare patch: la guida essenziale per vedere il vostro codice nel kernel
45 Guardate l'elemento **T:** per un determinato sottosistema nel file MAINTANERS
46 che troverete nei sorgenti, o semplicemente chiedete al manutentore nel caso
60 Descrivete ciò che sarà visibile agli utenti. Chiari incidenti nel sistema
83 nel dettaglio tecnico. È molto importante che descriviate la modifica
197 che usano ``git bisect`` per scovare i problemi potrebbero finire nel mezzo
198 della vostra serie in un punto qualsiasi; non vi saranno grati se nel mezzo
251 diversi sviluppatori la trascurano. Guardate nel file MAINTAINERS per trovare la
288 nel file MAINTAINERS), o almeno una notifica circa la vostra modifica,
289 cosicché l'informazione possa trovare la sua strada nel manuale. Le modifiche
311 Se decidete di copiare ed incollare la patch nel corpo dell'e-mail, state
336 nel changelog cosicché il prossimo revisore potrà meglio comprendere
361 Un tempo, le patch erano solite scomparire nel vuoto senza alcun commento,
369 aggiungendo la parola "RESEND" nel titolo::
409 indicata nel file; oppure
416 un'altra licenza) indicata nel file; oppure
454 sviluppo della patch, o che era nel suo percorso di consegna.
495 anche la persona (e indirizzo email) indicato nel From: dell'intestazione
544 l'adeguatezza ai fini dell'inclusione nel ramo principale del
569 venga integrate nel kernel.
576 della rimozione nel changelog della patch (subito dopo il separatore '---').
604 potere usare il comando ``git format-patch`` per ottenere patch nel formato
619 che verrà copiato permanentemente nel changelog per descrivere la patch.
624 anch'esse nel changelog.
628 - Qualsiasi altro commento che non deve finire nel changelog.
681 La riga ``from`` dev'essere la prima nel corpo del messaggio ed è nel
686 La riga ``from`` indica chi verrà accreditato nel changelog permanente come
688 l'autore da inserire nel changelog verrà usata la riga ``From``
691 Il corpo della spiegazione verrà incluso nel changelog permanente, per cui