Lines Matching full:non
26 C'è sempre una certa resistenza nel pubblicare patch finché non sono
27 veramente "pronte". Per semplici patch questo non è un problema.
34 Quando pubblicate del codice che non è considerato pronto per l'inclusione,
98 - La serie di patch che pubblicherete, quasi sicuramente, non sarà
102 sono interessati in modifiche che siano discrete e indipendenti, non
113 - Giusto per riaffermare quando detto sopra: non mischiate diversi tipi di
128 - Però, non strafate. Una volta uno sviluppatore pubblicò una serie di 500
129 patch che modificavano un unico file - un atto che non lo rese la persona
136 finché l'ultima patch della serie non abilita tutto quanto. Quando è
151 ma il lavoro non è davvero finito. Ogni patch deve essere preparata con
157 ma nel dubbio non fa di certo male aggiungerlo.
204 Non serve dirlo, un changelog dovrebbe essere il testo usato nel messaggio
248 Codice che non presenta una firma appropriata non potrà essere integrato.
269 che hanno verificato il codice e ci hanno fatto sapere quando le cose non
284 - Siete sicuri che il vostro programma di posta non corromperà le patch?
286 dai programmi di posta non funzioneranno per chi le riceve, e spesso
287 non verranno nemmeno esaminate in dettaglio. Se avete un qualsiasi dubbio,
294 - Siete sicuri che la vostra patch non contenga sciocchi errori? Dovreste
296 problemi riportati. Per favore tenete ben presente che checkpatch.pl non è
299 i suggerimenti di checkpatch.pl rende il codice peggiore, allora non fatelo.
301 Le patch dovrebbero essere sempre inviate come testo puro. Per favore non
308 incoraggia le persone a peccare nell'invio di tante copie; non presumente che
336 Linus Torvalds, e lasciare che sia lui ad integrarle,solitamente non è la
339 vorreste che siano questi manutentori ad integrare le vostre patch. Se non
354 introduttiva come parte zero. Tuttavia questa convenzione non è universalmente
355 seguita; se la usate, ricordate che le informazioni nell'introduzione non