Lines Matching full:per
11 Prima o poi arriva il momento in cui il vostro lavoro è pronto per essere
12 presentato alla comunità per una revisione ed eventualmente per la sua
15 e di procedure per la pubblicazione delle patch; seguirle renderà la vita
27 veramente "pronte". Per semplici patch questo non è un problema.
34 Quando pubblicate del codice che non è considerato pronto per l'inclusione,
51 per compilare il codice per differenti architetture, eccetera.
61 - Siate certi d'avere i diritti per pubblicare il codice. Se questo
62 lavoro è stato fatto per un datore di lavoro, egli avrà dei diritti su
73 La preparazione delle patch per la pubblicazione può richiedere una quantità
77 Le patch devono essere preparate per una specifica versione del kernel.
84 Per facilitare una revisione e una verifica più estesa, potrebbe diventare
85 necessaria la produzione di versioni per -mm, linux-next o i sorgenti di un
103 alla strada che avete percorso per ottenerle.
108 per esempio), ma dovrebbero essere concettualmente piccole da permettere
113 - Giusto per riaffermare quando detto sopra: non mischiate diversi tipi di
115 per la sicurezza, riorganizza alcune strutture, e riformatta il codice,
123 comando "git bisect" viene usato per trovare delle regressioni; se il
142 Lavorare per creare la serie di patch perfetta potrebbe essere frustrante
150 Quindi adesso avete una serie perfetta di patch pronte per la pubblicazione,
153 il suo scopo. Per ottenerlo, ogni patch sarà composta dai seguenti elementi:
160 messaggio dovrebbe essere sufficiente per far comprendere al lettore lo
163 seguito dallo scopo della patch. Per esempio:
194 citate, se possibile, il commit che lo introdusse (e per favore, quando
197 includeteli al fine d'aiutare gli altri a trovare soluzioni per lo stesso
200 modifiche e come gli altri dovrebbero agire per applicarle. In generale,
207 - La patch stessa, nel formato unificato per patch ("-u"). Usare
209 si riferisce, rendendo il risultato più facile da leggere per gli altri.
220 Un'altra etichetta viene usata per fornire collegamenti a pagine web contenenti
221 maggiori informazioni, per esempio una discussione avvenuta precedentemente
227 Alcuni manutentori aggiungono quest'etichetta alla patch per fare riferimento
244 Un altro tipo di etichetta viene usato per indicare chi ha contribuito allo
252 di sottomettere la patch per l'integrazione nel kernel. Questo rappresenta
259 sviluppatori; viene usato per assegnare più autori (in aggiunta a quello
271 - Reviwed-by: menziona lo sviluppatore che ha revisionato la patch; per
276 questa patch; quest'etichetta viene usata per dare credito alle persone che
303 dai programmi di posta non funzioneranno per chi le riceve, e spesso
313 problemi riportati. Per favore tenete ben presente che checkpatch.pl non è
315 ragionamenti su come debba essere una patch per il kernel. Se seguire
318 Le patch dovrebbero essere sempre inviate come testo puro. Per favore non
319 inviatele come allegati; questo rende molto più difficile, per i revisori,
335 utile per vedere chi altri ha modificato i file su cui state lavorando.
359 Le patch devono avere anche un buon oggetto. Il tipico formato per l'oggetto
368 nn/mm può essere omesso per una serie composta da una singola patch.
373 faranno parte del changelog del kernel. Quindi per favore, assicuratevi che
378 come un unico *thread*. Strumenti come git e quilt hanno comandi per inviare
380 e state usando git, per favore state alla larga dall'opzione --chain-reply-to
381 per evitare di creare un annidamento eccessivo.