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
35 Quando pubblicate del codice che non è considerato pronto per l'inclusione,
52 per compilare il codice per differenti architetture, eccetera.
62 - Siate certi d'avere i diritti per pubblicare il codice. Se questo
63 lavoro è stato fatto per un datore di lavoro, egli avrà dei diritti su
74 La preparazione delle patch per la pubblicazione può richiedere una quantità
78 Le patch devono essere preparate per una specifica versione del kernel.
86 necessaria la produzione di versioni per -mm, linux-next o i sorgenti di un
104 alla strada che avete percorso per ottenerle.
109 per esempio), ma dovrebbero essere concettualmente piccole da permettere
114 - Giusto per riaffermare quando detto sopra: non mischiate diversi tipi di
116 per la sicurezza, riorganizza alcune strutture, e riformatta il codice,
124 comando "git bisect" viene usato per trovare delle regressioni; se il
143 Lavorare per creare la serie di patch perfetta potrebbe essere frustrante
151 Quindi adesso avete una serie perfetta di patch pronte per la pubblicazione,
161 messaggio dovrebbe essere sufficiente per far comprendere al lettore lo
195 citate, se possibile, il commit che lo introdusse (e per favore, quando
198 includeteli al fine d'aiutare gli altri a trovare soluzioni per lo stesso
201 modifiche e come gli altri dovrebbero agire per applicarle. In generale,
208 - La patch stessa, nel formato unificato per patch ("-u"). Usare
210 si riferisce, rendendo il risultato più facile da leggere per gli altri.
212 Dovreste evitare di includere nelle patch delle modifiche per file
213 irrilevanti (quelli generati dal processo di generazione, per esempio, o i file
217 Le etichette sopra menzionante sono usate per descrivere come i vari
230 di sottomettere la patch per l'integrazione nel kernel. Questo rappresenta
237 sviluppatori; viene usato per assegnare più autori (in aggiunta a quello
249 - Reviwed-by: menziona lo sviluppatore che ha revisionato la patch; per
254 questa patch; quest'etichetta viene usata per dare credito alle persone
272 dai programmi di posta non funzioneranno per chi le riceve, e spesso
284 ragionamenti su come debba essere una patch per il kernel. Se seguire
288 inviatele come allegati; questo rende molto più difficile, per i revisori,
304 utile per vedere chi altri ha modificato i file su cui state lavorando.
328 Le patch devono avere anche un buon oggetto. Il tipico formato per l'oggetto
337 nn/mm può essere omesso per una serie composta da una singola patch.
342 faranno parte del changelog del kernel. Quindi per favore, assicuratevi che
347 come un unico *thread*. Strumenti come git e quilt hanno comandi per inviare
349 e state usando git, per favore state alla larga dall'opzione --chain-reply-to
350 per evitare di creare un annidamento eccessivo.