Lines Matching refs:le
14 suggerimenti che aumenteranno significativamente le probabilità di vedere le
25 Questa documentazione assume che sappiate usare ``git`` per preparare le patch.
44 sorgenti e desiderano che le patch siano preparate basandosi su di essi.
51 Descrivete le vostre modifiche
66 singolarmente le patch dai sorgenti principali; quindi, includete tutte
67 le informazioni che possono essere utili a capire le vostre modifiche:
68 le circostanze che causano il problema, estratti da dmesg, descrizioni di
72 Quantificare le ottimizzazioni e i compromessi. Se affermate di aver
73 migliorato le prestazioni, il consumo di memoria, l'impatto sollo stack,
76 che non sono ovvi. Solitamente le ottimizzazioni non sono gratuite, ma sono
98 manutentori di un sottosistema vadano a cercare le versioni precedenti per
102 le versioni precedenti della patch.
104 Descrivete le vostro modifiche usando l'imperativo, per esempio "make xyzzy
171 Separate le vostre modifiche
229 - ERROR: le cose sono molto probabilmente sbagliate
230 - WARNING: le cose necessitano d'essere revisionate con attenzione
231 - CHECK: le cose necessitano di un pensierino
233 Dovreste essere in grado di giustificare tutte le eventuali violazioni rimaste
250 dovrebbe essere usata per inviare tutte le patch, ma il traffico è tale per cui
253 patch riceverà molta più attenzione. Tuttavia, per favore, non spammate le liste
286 Se le modifiche hanno effetti sull'interfaccia con lo spazio utente, per favore
287 inviate una patch per le pagine man ai manutentori di suddette pagine (elencati
297 le modifiche che sottomettete. Per uno sviluppatore è importante
298 essere in grado di "citare" le vostre modifiche, usando normali
302 Per questa ragione tutte le patch devono essere inviate via e-mail
321 Eccezione: se il vostro servizio di posta storpia le patch, allora qualcuno
345 le differenze rispetto a sottomissioni precedenti (vedere
349 le raccomandazioni sui programmi di posta elettronica e l'etichetta da usare
357 Dopo che avete inviato le vostre modifiche, siate pazienti e aspettate.
361 Un tempo, le patch erano solite scomparire nel vuoto senza alcun commento,
364 aver inviato le patch correttamente. Aspettate almeno una settimana prima di
365 rinviare le modifiche o sollecitare i revisori - probabilmente anche di più
383 altri sviluppatori del kernel di distinguere facilmente le patch dalle altre
414 le cui modifiche sono interamente o in parte mie, in accordo con
423 tutte le informazioni personali che invio con essi, inclusa la mia
425 ridistribuito in accordo con questo progetto o le licenze
466 integra le patch convertirà un "sì, mi sembra che vada bene" in un Acked-by:
547 (b) Tutti i problemi e le domande riguardanti la patch sono stati
559 le possibili situazioni.
568 loro serietà nella revisione, accrescerà le probabilità che la vostra patch
572 un revisore, le etichette Tested-by o Reviewed-by devono essere
579 dalla persona nominata e le da credito. Tenete a mente che questa etichetta
594 in copia conoscenza stable@vger.kernel.org su tutte le patch per
602 Questa sezione descrive il formato che dovrebbe essere usato per le patch.
603 Notate che se state usando un repositorio ``git`` per salvare le vostre patch
606 le seguenti istruzioni.
633 per ordinare le patch alfabeticamente - tutti i programmi di posta hanno
642 di file. Non utilizzate la stessa ``summary phrase`` per tutte le patch in
650 cercare la ``summary phrase`` su internet per leggere le discussioni che la
651 riguardano. Potrebbe anche essere l'unica cosa che le persone vedranno
661 le parentesi quadre "Subject: [PATCH <tag>...] <summary phrase>".
663 indicano come la patch dovrebbe essere trattata. Fra le etichette più comuni
670 sviluppatori capiranno l'ordine in cui le patch dovrebbero essere
695 eccetera) è particolarmente utile per le persone che potrebbero cercare fra
712 Un ``diffstat`` è particolarmente utile per le patch grandi. Se
713 includete un ``diffstat`` dopo ``---``, usate le opzioni ``-p 1 -w70``
721 ``patch changelogs`` che descrivere le differenze fra le versioni
751 davvero utili. Per esempio, le sequenze iniziali di avvio sono uniche
757 Quindi, per rendere utile un *backtrace* dovreste eliminare le