Lines Matching refs:le
14 suggerimenti che aumenteranno significativamente le probabilità di vedere le
27 controllo di versione ``git``; se utilizzate ``git`` per preparare le vostre
43 sorgenti e desiderano che le patch siano preparate basandosi su di essi.
55 Se dovete produrre le vostre patch a mano, usate ``diff -up`` o ``diff -uprN``
56 per crearle. Git produce di base le patch in questo formato; se state
59 Tutte le modifiche al kernel Linux avvengono mediate patch, come descritte
64 alla quale si riferiscono le diverse modifiche - questo rende il risultato
98 Se le vostre modifiche producono molte differenze, allora dovrete dividerle
99 in patch indipendenti che modificano le cose in passi logici; leggete
109 2) Descrivete le vostre modifiche
124 singolarmente le patch dai sorgenti principali; quindi, includete tutte
125 le informazioni che possono essere utili a capire le vostre modifiche:
126 le circostanze che causano il problema, estratti da dmesg, descrizioni di
130 Quantificare le ottimizzazioni e i compromessi. Se affermate di aver
131 migliorato le prestazioni, il consumo di memoria, l'impatto sollo stack,
134 che non sono ovvi. Solitamente le ottimizzazioni non sono gratuite, ma sono
156 manutentori di un sottosistema vadano a cercare le versioni precedenti per
160 le versioni precedenti della patch.
162 Descrivete le vostro modifiche usando l'imperativo, per esempio "make xyzzy
213 3) Separate le vostre modifiche
271 - ERROR: le cose sono molto probabilmente sbagliate
272 - WARNING: le cose necessitano d'essere revisionate con attenzione
273 - CHECK: le cose necessitano di un pensierino
275 Dovreste essere in grado di giustificare tutte le eventuali violazioni rimaste
294 patch riceverà molta più attenzione. Tuttavia, per favore, non spammate le
331 Se le modifiche hanno effetti sull'interfaccia con lo spazio utente, per favore
332 inviate una patch per le pagine man ai manutentori di suddette pagine (elencati
338 Per le piccole patch potreste aggiungere in CC l'indirizzo
340 le patch "banali". Date uno sguardo al file MAINTAINERS per vedere chi
351 specifico per un'architettura, dato che le persone copiano, fintanto che
361 le modifiche che sottomettete. Per uno sviluppatore è importante
362 essere in grado di "citare" le vostre modifiche, usando normali
366 Per questa ragione tutte le patch devono essere inviate via e-mail
381 Eccezione: se il vostro servizio di posta storpia le patch, allora qualcuno
416 Dopo che avete inviato le vostre modifiche, siate pazienti e aspettate.
420 Un tempo, le patch erano solite scomparire nel vuoto senza alcun commento,
423 aver inviato le patch correttamente. Aspettate almeno una settimana prima di
424 rinviare le modifiche o sollecitare i revisori - probabilmente anche di più
432 altri sviluppatori del kernel di distinguere facilmente le patch dalle altre
461 le cui modifiche sono interamente o in parte mie, in accordo con
470 tutte le informazioni personali che invio con essi, inclusa la mia
472 ridistribuito in accordo con questo progetto o le licenze
487 modificare leggermente le patch che avete ricevuto al fine di poterle
498 questo renderà abbastanza visibile chi è responsabile per le modifiche
507 le modifiche, e proteggere i mittenti dalle lamentele. Notate che in nessuna
553 integra le patch convertirà un "sì, mi sembra che vada bene" in un Acked-by:
633 (b) Tutti i problemi e le domande riguardanti la patch sono stati
645 le possibili situazioni.
654 loro serietà nella revisione, accrescerà le probabilità che la vostra patch
658 dalla persona nominata e le da credito. Tenete a mente che questa etichetta
675 Questa sezione descrive il formato che dovrebbe essere usato per le patch.
676 Notate che se state usando un repositorio ``git`` per salvare le vostre patch
679 le seguenti istruzioni.
706 per ordinare le patch alfabeticamente - tutti i programmi di posta hanno
715 di file. Non utilizzate la stessa ``summary phrase`` per tutte le patch in
723 cercare la ``summary phrase`` su internet per leggere le discussioni che la
724 riguardano. Potrebbe anche essere l'unica cosa che le persone vedranno
734 le parentesi quadre "Subject: [PATCH <tag>...] <summary phrase>".
736 indicano come la patch dovrebbe essere trattata. Fra le etichette più comuni
741 Questo assicura che gli sviluppatori capiranno l'ordine in cui le patch
764 eccetera) è particolarmente utile per le persone che potrebbero cercare fra
776 Un ``diffstat`` è particolarmente utile per le patch grandi. Altri commenti
779 di commenti potrebbe essere quello di descrivere le differenze fra le versioni
782 Se includete un ``diffstat`` dopo ``---``, usate le opzioni ``-p 1 -w70``
834 Alcuni manutentori (incluso Linus) vogliono vedere le richieste di *pull*
848 qualcuno le prenda, create una etichetta firmata col comando ``git tag -s``.
854 Se i sorgenti da cui il manutentore prenderà le patch non sono gli stessi del