Lines Matching refs:il
11 Prima o poi arriva il momento in cui il vostro lavoro è pronto per essere
29 Ma quando il lavoro è di una certa complessità, c'è molto da guadagnare
30 dai riscontri che la comunità può darvi prima che completiate il lavoro.
39 ma quelli che lo faranno penseranno di potervi aiutare a condurre il vostro
49 - Verificare il codice fino al massimo che vi è consentito. Usate gli
50 strumenti di debug del kernel, assicuratevi che il kernel compili con
52 per compilare il codice per differenti architetture, eccetera.
54 - Assicuratevi che il vostro codice sia conforme alla linee guida del
58 Se è così, dovreste eseguire dei *benchmark* che mostrino il loro
62 - Siate certi d'avere i diritti per pubblicare il codice. Se questo
67 Come regola generale, pensarci un po' di più prima di inviare il codice
82 un -rc - piuttosto che creare il vostro ramo da quello principale in un punto
93 patch; tutto il resto dovrebbe essere preparato come una serie logica di
116 per la sicurezza, riorganizza alcune strutture, e riformatta il codice,
121 correttamente; se la vostra serie di patch si interrompe a metà il
123 parziale di una serie di patch è uno scenario comune nel quale il
124 comando "git bisect" viene usato per trovare delle regressioni; se il
140 problema anche se il baco si trova altrove. Possibilmente, quando una
144 perché richiede un certo tempo e soprattutto dopo che il "vero lavoro" è
152 ma il lavoro non è davvero finito. Ogni patch deve essere preparata con
154 il suo scopo. Per ottenerlo, ogni patch sarà composta dai seguenti elementi:
163 solitamente, presenta in testa il nome del sottosistema a cui si riferisce,
178 Gli elementi qui sopra, assieme, formano il changelog di una patch.
187 gli utenti che vogliono sapere com'è cambiato il kernel, e molti altri.
193 il limite di una sola riga. La descrizione dettagliata può spiegare meglio
195 citate, se possibile, il commit che lo introdusse (e per favore, quando
196 citate un commit aggiungete sia il suo identificativo che il titolo),
197 Se il problema è associabile ad un file di log o all' output del compilatore,
202 più riuscirete ad entrare nei panni di tutti quelli che leggeranno il
203 vostro changelog, meglio sarà il changelog (e il kernel nel suo insieme).
205 Non serve dirlo, un changelog dovrebbe essere il testo usato nel messaggio
209 l'opzione "-p" assocerà alla modifica il nome della funzione alla quale
210 si riferisce, rendendo il risultato più facile da leggere per gli altri.
220 quello che segue è un breve riassunto. Ognuna di queste righe ha il seguente
229 - Signed-off-by: questa è la certificazione che lo sviluppatore ha il diritto
231 il consenso verso il certificato d'origine degli sviluppatori, il testo
243 - Acked-by: indica il consenso di un altro sviluppatore (spesso il manutentore
253 - Reported-by: menziona l'utente che ha riportato il problema corretto da
255 che hanno verificato il codice e ci hanno fatto sapere quando le cose non
262 "Cc:" può essere aggiunta senza il permesso esplicito della persona menzionata.
270 - Siete sicuri che il vostro programma di posta non corromperà le patch?
283 più intelligente di voi, nonostante sia il risultato di un certa quantità di
284 ragionamenti su come debba essere una patch per il kernel. Se seguire
285 i suggerimenti di checkpatch.pl rende il codice peggiore, allora non fatelo.
293 potrebbero esserne interessate. Al contrario di altri progetti, il kernel
299 in precedenza, il file MAINTAINERS è il primo luogo dove cercare i nomi
335 dove "nn" è il numero ordinale della patch, "mm" è il numero totale delle patch
336 nella serie, e "subsys" è il nome del sottosistema interessato. Chiaramente,