Lines Matching refs: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
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.
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,
160 messaggio dovrebbe essere sufficiente per far comprendere al lettore lo
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
286 dai programmi di posta non funzioneranno per chi le riceve, e spesso
298 ragionamenti su come debba essere una patch per il kernel. Se seguire
302 inviatele come allegati; questo rende molto più difficile, per i revisori,
318 utile per vedere chi altri ha modificato i file su cui state lavorando.
342 Le patch devono avere anche un buon oggetto. Il tipico formato per l'oggetto
351 nn/mm può essere omesso per una serie composta da una singola patch.
356 faranno parte del changelog del kernel. Quindi per favore, assicuratevi che
361 come un unico *thread*. Strumenti come git e quilt hanno comandi per inviare
363 e state usando git, per favore state alla larga dall'opzione --chain-reply-to
364 per evitare di creare un annidamento eccessivo.