Lines Matching refs:un
11 Una persona o un'azienda che volesse inviare una patch al kernel potrebbe
17 Questo documento contiene un vasto numero di suggerimenti concisi. Per maggiori
21 punti da verificare prima di inviare del codice. Se state inviando un driver,
34 Se non avete un repositorio coi sorgenti del kernel più recenti, allora usate
43 Guardate l'elemento **T:** per un determinato sottosistema nel file MAINTANERS
52 Descrivete il vostro problema. Esiste sempre un problema che via ha spinto
53 ha fare il vostro lavoro, che sia la correzione di un baco da una riga o una
62 la maggior parte delle installazioni Linux usa un kernel che arriva dai
67 un incidente di sistema, prestazioni di una regressione, picchi di latenza,
75 un compromesso fra l'uso di CPU, la memoria e la leggibilità; o, quando si
82 in un inglese semplice cosicché i revisori possano verificare che il codice si
85 I manutentori vi saranno grati se scrivete la descrizione della patch in un
87 ``git``, come un "commit log". Leggete :ref:`it_explicit_in_reply_to`.
89 Risolvete solo un problema per patch. Se la vostra descrizione inizia ad
90 essere lunga, potrebbe essere un segno che la vostra patch necessita d'essere
96 manutentori di un sottosistema vadano a cercare le versioni precedenti per
98 descrizione devono essere un'unica cosa. Questo aiuta i manutentori e i
107 Se la patch corregge un baco conosciuto, fare riferimento a quel baco inserendo
135 Se la vostra patch corregge un baco in un commit specifico, per esempio avete
136 trovato un problema usando ``git bisect``, per favore usate l'etichetta
163 Per esempio, se i vostri cambiamenti per un singolo driver includono
166 un aggiornamento dell'API e un nuovo driver che lo sfrutta, allora separateli
170 queste modifiche in una singola patch. Dunque, un singolo cambiamento logico
177 Se al fine di ottenere un cambiamento completo una patch dipende da un'altra,
185 della vostra serie in un punto qualsiasi; non vi saranno grati se nel mezzo
202 Un'eccezione importante si ha quando del codice viene spostato da un file
203 ad un altro -- in questo caso non dovreste modificare il codice spostato
211 di stile dovrebbe essere visto come una guida, non come un sostituto al
218 - CHECK: le cose necessitano di un pensierino
228 interessati dalle modifiche; date un'occhiata al file MAINTAINERS e alla storia
230 scripts/get_maintainer.pl può esservi d'aiuto. Se non riuscite a trovare un
238 lista di discussione dedicata ad un sottosistema; probabilmente lì la vostra
243 vger.kernel.org; potete trovare un loro elenco alla pagina
255 Se avete una patch che corregge un baco di sicurezza che potrebbe essere
256 sfruttato, inviatela a security@kernel.org. Per bachi importanti, un breve
263 Patch che correggono bachi importanti su un kernel già rilasciato, dovrebbero
292 specifico per un'architettura, dato che le persone copiano, fintanto che
294 - qualsiasi modifica dell'autore/manutentore di un file (in pratica
320 La patch non deve essere un allegato MIME, compresso o meno. Molti
321 dei più popolari programmi di posta elettronica non trasmettono un allegato
323 Inoltre, un allegato MIME rende l'attività di Linus più laboriosa, diminuendo
338 rispondere a questi commenti; ignorare i revisori è un ottimo modo per
340 modifica del codice quasi certamente dovrebbero portare ad un commento
345 ringraziarli per il loro tempo. Revisionare codice è un lavoro faticoso e che
368 Potete anche rinviare la patch, o la serie di patch, dopo un paio di settimane
411 (b) Il contributo è basato su un lavoro precedente che, nei limiti
412 della mia conoscenza, è coperto da un'appropriata licenza
416 un'altra licenza) indicata nel file; oppure
422 contributi sono pubblici e che un registro dei contributi (incluse
466 integra le patch convertirà un "sì, mi sembra che vada bene" in un Acked-by:
469 Acked-by: non indica l'accettazione di un'intera patch. Per esempio, quando
470 una patch ha effetti su diversi sottosistemi e ha un Acked-by: da un
529 (su un qualche sistema) dalla persona citata. Questa etichetta informa i
530 manutentori che qualche verifica è stata fatta, fornisce un mezzo per trovare
560 L'etichetta Reviewed-by è la dichiarazione di un parere sulla bontà di
570 Quando si riceve una email sulla lista di discussione da un tester o
571 un revisore, le etichette Tested-by o Reviewd-by devono essere
579 non dovrebbe essere aggiunta senza un permesso esplicito, specialmente se
580 l'idea non è stata pubblicata in un forum pubblico. Detto ciò, dando credito
584 L'etichetta Fixes: indica che la patch corregge un problema in un commit
585 precedente. Serve a chiarire l'origine di un baco, il che aiuta la revisione
588 Questo è il modo suggerito per indicare che un baco è stato corretto nella
591 Da notare che aggiungere un tag "Fixes:" non esime dalle regole
600 Notate che se state usando un repositorio ``git`` per salvare le vostre patch
638 il contenuto della patch. La ``summary phrase`` non dovrebbe essere un nome
643 Ricordatevi che la ``summary phrase`` della vostra email diventerà un
654 brevi e descrittivi è una bella sfida, ma questo è quello che fa un riassunto
657 La ``summary phrase`` può avere un'etichetta (*tag*) di prefisso racchiusa fra
689 deve aver senso per un lettore esperto che è ha dimenticato i dettagli della
698 Se la patch corregge un errore di compilazione, non sarà necessario
707 Aggiungere il ``diffstat`` dopo ``---`` è un buon uso di questo spazio, per
710 includete un ``diffstat`` dopo ``---``, usate le opzioni ``-p 1 -w70``
745 che portano ad un problema. Tuttavia, non tutti i *backtrace* sono
752 Quindi, per rendere utile un *backtrace* dovreste eliminare le
754 problema. Ecco un esempio di un *backtrace* essenziale::
770 precedente, per esempio per collegare la correzione di un baco con l'e-mail
773 In questo modo versioni multiple di una patch non diventeranno un'ingestibile
774 giungla di riferimenti all'interno dei programmi di posta. Se un collegamento
788 Greg Kroah-Hartman, "Come scocciare un manutentore di un sottosistema"