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.
211 Dovreste evitare di includere nelle patch delle modifiche per file
212 irrilevanti (quelli generati dal processo di generazione, per esempio, o i file
225 Un'altra etichetta viene usata per fornire collegamenti a pagine web contenenti
226 maggiori informazioni, per esempio un rapporto circa il baco risolto dalla
231 Alcuni manutentori aggiungono quest'etichetta alla patch per fare riferimento
236 Un terzo tipo di etichetta viene usato per indicare chi ha contribuito allo
244 di sottomettere la patch per l'integrazione nel kernel. Questo rappresenta
251 sviluppatori; viene usato per assegnare più autori (in aggiunta a quello
263 - Reviwed-by: menziona lo sviluppatore che ha revisionato la patch; per
268 questa patch; quest'etichetta viene usata per dare credito alle persone che
289 dai programmi di posta non funzioneranno per chi le riceve, e spesso
299 problemi riportati. Per favore tenete ben presente che checkpatch.pl non è
301 ragionamenti su come debba essere una patch per il kernel. Se seguire
304 Le patch dovrebbero essere sempre inviate come testo puro. Per favore non
305 inviatele come allegati; questo rende molto più difficile, per i revisori,
321 utile per vedere chi altri ha modificato i file su cui state lavorando.
345 Le patch devono avere anche un buon oggetto. Il tipico formato per l'oggetto
354 nn/mm può essere omesso per una serie composta da una singola patch.
359 faranno parte del changelog del kernel. Quindi per favore, assicuratevi che
364 come un unico *thread*. Strumenti come git e quilt hanno comandi per inviare
366 e state usando git, per favore state alla larga dall'opzione --chain-reply-to
367 per evitare di creare un annidamento eccessivo.