Lines Matching refs:la
12 presentato alla comunità per una revisione ed eventualmente per la sua
14 la comunità di sviluppo del kernel ha elaborato un insieme di convenzioni
15 e di procedure per la pubblicazione delle patch; seguirle renderà la vita
29 dai riscontri che la comunità può darvi prima che completiate il lavoro.
73 La preparazione delle patch per la pubblicazione può richiedere una quantità
85 necessaria la produzione di versioni per -mm, linux-next o i sorgenti di un
111 verificare la veridicità.
115 per la sicurezza, riorganizza alcune strutture, e riformatta il codice,
116 ci sono buone probabilità che venga ignorata e che la correzione importante
120 correttamente; se la vostra serie di patch si interrompe a metà il
124 risultato è un kernel guasto, renderete la vita degli sviluppatori più
129 patch che modificavano un unico file - un atto che non lo rese la persona
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,
156 è necessaria solo se state passando la patch di qualcun altro via email,
159 - Una descrizione di una riga che spieghi cosa fa la patch. Questo
179 vale la pena spendere qualche parola in più al riguardo. Quando scrivete
182 revisori che devono decidere se la patch debba essere inclusa o no,
183 le distribuzioni e altri manutentori che cercano di valutare se la patch
185 chiederanno se la patch è la causa di un problema che stanno cercando,
190 A questo scopo, la riga riassuntiva dovrebbe descrivere gli effetti della
191 modifica e la motivazione della patch nel modo migliore possibile nonostante
198 problema. Se la modifica ha lo scopo di essere di supporto a sviluppi
243 - Signed-off-by: questa è la certificazione che lo sviluppatore ha il diritto
244 di sottomettere la patch per l'integrazione nel kernel. Questo rappresenta
250 - Co-developed-by: indica che la patch è stata cosviluppata da diversi
260 - Tested-by: menziona la persona che ha verificato la patch e l'ha trovata
263 - Reviwed-by: menziona lo sviluppatore che ha revisionato la patch; per
264 maggiori dettagli leggete la dichiarazione dei revisori in
272 - Cc: la persona menzionata ha ricevuto una copia della patch ed ha avuto
278 Inviare la modifica
281 Prima di inviare la vostra patch, ci sarebbero ancora un paio di cose di cui
288 inviate la patch a voi stessi e verificate che sia integra.
294 - Siete sicuri che la vostra patch non contenga sciocchi errori? Dovreste
303 citare parti della patch che si vogliono commentare. Invece, mettete la vostra
326 - Se state correggendo un baco, pensate se la patch dovrebbe essere inclusa
327 nel prossimo rilascio stabile. Se è così, la lista di discussione
334 pensiate che sia colui che, eventualmente, accetterà la vostra patch e
335 la integrerà. Nonostante sia possibile inviare patch direttamente a
336 Linus Torvalds, e lasciare che sia lui ad integrarle,solitamente non è la
355 seguita; se la usate, ricordate che le informazioni nell'introduzione non
359 In generale, la seconda parte e quelle successive di una patch "composta"
362 gruppi di patch con la struttura appropriata. Se avete una serie lunga