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
36 Se non avete un repositorio coi sorgenti del kernel più recenti, allora usate
45 Guardate l'elemento **T:** per un determinato sottosistema nel file MAINTANERS
54 Descrivete il vostro problema. Esiste sempre un problema che via ha spinto
55 ha fare il vostro lavoro, che sia la correzione di un baco da una riga o una
64 la maggior parte delle installazioni Linux usa un kernel che arriva dai
69 un incidente di sistema, prestazioni di una regressione, picchi di latenza,
77 un compromesso fra l'uso di CPU, la memoria e la leggibilità; o, quando si
84 in un inglese semplice cosicché i revisori possano verificare che il codice si
87 I manutentori vi saranno grati se scrivete la descrizione della patch in un
89 ``git``, come un "commit log". Leggete :ref:`it_the_canonical_patch_format`.
91 Risolvete solo un problema per patch. Se la vostra descrizione inizia ad
92 essere lunga, potrebbe essere un segno che la vostra patch necessita d'essere
98 manutentori di un sottosistema vadano a cercare le versioni precedenti per
100 descrizione devono essere un'unica cosa. Questo aiuta i manutentori e i
128 precedentemente o di un documento sul presente sul web, allora fatevi
131 Per esempio, se la vostra patch corregge un baco potete aggiungere
132 quest'etichetta per fare riferimento ad un rapporto su una lista di discussione
133 o un *bug tracker*. Un altro esempio; potete usare quest'etichetta per far
139 servizio d'archiviazione lore.kernel.org. Per create un collegamento URL è
152 Se il collegamento indirizza verso un rapporto su un baco risolto dalla patch,
163 Se la vostra patch corregge un baco in un commit specifico, per esempio avete
164 trovato un problema usando ``git bisect``, per favore usate l'etichetta
191 Per esempio, se i vostri cambiamenti per un singolo driver includono
194 un aggiornamento dell'API e un nuovo driver che lo sfrutta, allora separateli
198 queste modifiche in una singola patch. Dunque, un singolo cambiamento logico
205 Se al fine di ottenere un cambiamento completo una patch dipende da un'altra,
213 della vostra serie in un punto qualsiasi; non vi saranno grati se nel mezzo
230 Un'eccezione importante si ha quando del codice viene spostato da un file
231 ad un altro -- in questo caso non dovreste modificare il codice spostato
239 di stile dovrebbe essere visto come una guida, non come un sostituto al
246 - CHECK: le cose necessitano di un pensierino
256 discussione dei sottosistemi interessati dalle modifiche; date un'occhiata al
259 percorso alle vostre patch). Se non riuscite a trovare un manutentore per il
264 le patch, ma il volume ha raggiunto un livello tale d'aver spinto alcuni
273 lista di discussione dedicata ad un sottosistema; probabilmente lì la vostra
278 vger.kernel.org; potete trovare un loro elenco alla pagina
290 Se avete una patch che corregge un baco di sicurezza che potrebbe essere
291 sfruttato, inviatela a security@kernel.org. Per bachi importanti, un breve
298 Patch che correggono bachi importanti su un kernel già rilasciato, dovrebbero
336 La patch non deve essere un allegato MIME, compresso o meno. Molti
337 dei più popolari programmi di posta elettronica non trasmettono un allegato
339 Inoltre, un allegato MIME rende l'attività di Linus più laboriosa, diminuendo
354 rispondere a questi commenti; ignorare i revisori è un ottimo modo per
356 modifica del codice quasi certamente dovrebbero portare ad un commento
361 ringraziarli per il loro tempo. Revisionare codice è un lavoro faticoso e che
364 evidenziato. Quando inviate una versione successiva ricordatevi di aggiungere un
388 R: Perché incasina il normale ordine con cui si legge un testo.
399 D: Dovrei includere un blocco di citazione dopo la mia risposta?
417 Potete anche rinviare la patch, o la serie di patch, dopo un paio di settimane
460 (b) Il contributo è basato su un lavoro precedente che, nei limiti
461 della mia conoscenza, è coperto da un'appropriata licenza
465 un'altra licenza) indicata nel file; oppure
471 contributi sono pubblici e che un registro dei contributi (incluse
515 integra le patch convertirà un "sì, mi sembra che vada bene" in un Acked-by:
518 Acked-by: non indica l'accettazione di un'intera patch. Per esempio, quando
519 una patch ha effetti su diversi sottosistemi e ha un Acked-by: da un
577 Questa etichetta dovrebbe essere seguita da quella Closes: con un indirizzo al
583 (su un qualche sistema) dalla persona citata. Questa etichetta informa i
584 manutentori che qualche verifica è stata fatta, fornisce un mezzo per trovare
614 L'etichetta Reviewed-by è la dichiarazione di un parere sulla bontà di
624 Quando si riceve una email sulla lista di discussione da un tester o
625 un revisore, le etichette Tested-by o Reviewed-by devono essere
633 non dovrebbe essere aggiunta senza un permesso esplicito, specialmente se
634 l'idea non è stata pubblicata in un forum pubblico. Detto ciò, dando credito
638 L'etichetta Fixes: indica che la patch corregge un problema in un commit
639 precedente. Serve a chiarire l'origine di un baco, il che aiuta la revisione
642 Questo è il modo suggerito per indicare che un baco è stato corretto nella
645 Da notare che aggiungere un tag "Fixes:" non esime dalle regole
656 Notate che se state usando un repositorio ``git`` per salvare le vostre patch
694 il contenuto della patch. La ``summary phrase`` non dovrebbe essere un nome
699 Ricordatevi che la ``summary phrase`` della vostra email diventerà un
710 brevi e descrittivi è una bella sfida, ma questo è quello che fa un riassunto
713 La ``summary phrase`` può avere un'etichetta (*tag*) di prefisso racchiusa fra
745 deve aver senso per un lettore esperto che è ha dimenticato i dettagli della
754 Se la patch corregge un errore di compilazione, non sarà necessario
763 Aggiungere il ``diffstat`` dopo ``---`` è un buon uso di questo spazio, per
766 includete un ``diffstat`` dopo ``---``, usate le opzioni ``-p 1 -w70``
803 che portano ad un problema. Tuttavia, non tutti i *backtrace* sono
810 Quindi, per rendere utile un *backtrace* dovreste eliminare le
812 problema. Ecco un esempio di un *backtrace* essenziale::
828 precedente, per esempio per collegare la correzione di un baco con l'e-mail
831 In questo modo versioni multiple di una patch non diventeranno un'ingestibile
832 giungla di riferimenti all'interno dei programmi di posta. Se un collegamento
903 Greg Kroah-Hartman, "Come scocciare un manutentore di un sottosistema"