Lines Matching refs:una
11 Una persona o un'azienda che volesse inviare una patch al kernel potrebbe
13 una certa familiarità col "sistema". Questo testo è una raccolta di
21 per una lista di punti da verificare prima di inviare del codice. Se state
49 tar (come descritto in una delle prossime sezioni), ma questa è la via più
68 Per creare una patch per un singolo file, spesso è sufficiente fare::
79 Per creare una patch per molteplici file, dovreste spacchettare i sorgenti
90 ``dontdiff`` è una lista di file che sono generati durante il processo di
113 ha fare il vostro lavoro, che sia la correzione di un baco da una riga o una
123 sorgenti stabili o dai sorgenti di una distribuzione particolare che prende
127 un incidente di sistema, prestazioni di una regressione, picchi di latenza,
153 Quando inviate o rinviate una patch o una serie, includete la descrizione
168 il suo numero o il suo URL. Se la patch è la conseguenza di una discussione
169 su una lista di discussione, allora fornite l'URL all'archivio di quella
224 D'altro canto, se fate una singola modifica su più file, raggruppate tutte
225 queste modifiche in una singola patch. Dunque, un singolo cambiamento logico
226 è contenuto in una sola patch.
232 Se al fine di ottenere un cambiamento completo una patch dipende da un'altra,
233 va bene. Semplicemente scrivete una nota nella descrizione della patch per
236 Quando dividete i vostri cambiamenti in una serie di patch, prestate
243 Se non potete condensare la vostra serie di patch in una più piccola, allora
244 pubblicatene una quindicina alla volta e aspettate che vengano revisionate
253 Non farlo porta semplicemente a una perdita di tempo da parte dei revisori e
264 Prima di inviare una patch, verificatene lo stile usando l'apposito
266 di stile dovrebbe essere visto come una guida, non come un sostituto al
267 giudizio umano. Se il vostro codice è migliore nonostante una violazione
282 Dovreste sempre inviare una copia della patch ai manutentori dei sottosistemi
289 Normalmente, dovreste anche scegliere una lista di discussione a cui inviare
310 Se avete una patch che corregge un baco di sicurezza che potrebbe essere
332 inviate una patch per le pagine man ai manutentori di suddette pagine (elencati
333 nel file MAINTAINERS), o almeno una notifica circa la vostra modifica,
343 Le patch banali devono rientrare in una delle seguenti categorie:
364 una porzione specifica del vostro codice.
391 Le grosse modifiche non sono adatte ad una lista di discussione, e nemmeno
393 di spazio, allora caricatela in una spazio accessibile su internet fornendo
403 ad una modifica del codice quasi certamente dovrebbero portare ad un commento
422 in una settimana o poco più; se questo non dovesse accadere, assicuratevi di
423 aver inviato le patch correttamente. Aspettate almeno una settimana prima di
444 La firma è una semplice riga alla fine della descrizione della patch che
475 poi dovete solo aggiungere una riga che dice::
491 controproducente e una totale perdita di tempo ed energia. La regola (b)
494 Per risolvere questo problema dovreste aggiungere una riga, fra l'ultimo
497 nome o indirizzo email fra parentesi quadre, seguito da una breve descrizione;
543 Se una persona non è direttamente coinvolta con la preparazione o gestione
546 una riga Acked-by:.
557 una patch ha effetti su diversi sottosistemi e ha un Acked-by: da un
563 Se una persona ha avuto l'opportunità di commentare la patch, ma non lo ha
566 alcunché - ma dovrebbe indicare che la persona ha ricevuto una copia della
572 associato all'etichetta From:) quando più persone lavorano ad una patch. Dato
585 Esempio di una patch sottomessa dall'autore in From:::
595 Esempio di una patch sottomessa dall'autore Co-developed-by:::
629 (a) Ho effettuato una revisione tecnica di questa patch per valutarne
638 sottomissione, credo che sia, in questo momento, (1) una modifica
648 una modifica che si ritiene appropriata e senza alcun problema tecnico
681 L'oggetto di una patch canonica è la riga::
685 Il corpo di una patch canonica contiene i seguenti elementi:
688 da una riga vuota (necessaria soltanto se la persona che invia la
716 una serie (dove una ``serie di patch`` è una sequenza ordinata di diverse
730 brevi e descrittivi è una bella sfida, ma questo è quello che fa un riassunto
737 ci sono quelle di versione che vengono usate quando una patch è stata inviata
795 potrebbe essere d'aiuto per associare una patch ad una discussione
799 In questo modo versioni multiple di una patch non diventeranno un'ingestibile
802 ad una versione precedente di una serie di patch (per esempio, potete usarlo
808 Se avete una serie di patch, potrebbe essere più conveniente per un manutentore
812 una lista di discussione. Di conseguenza, molti manutentori sono riluttanti
814 quindi sconosciuti. Se siete in dubbio, potete fare una richiesta di *pull*
815 come messaggio introduttivo ad una normale pubblicazione di patch, così
820 ramo su una singola riga; dovrebbe essere più o meno così::
829 che dica cos'è incluso, una lista delle patch usando ``git shortlog``, e una
835 da commit firmati con GPG; questo fornisce una maggiore garanzia sul fatto
841 creare una chiave GNUPG ed averla fatta firmare da uno o più sviluppatori
848 qualcuno le prenda, create una etichetta firmata col comando ``git tag -s``.
849 Questo creerà una nuova etichetta che identifica l'ultimo commit della serie
850 contenente una firma creata con la vostra chiave privata. Avrete anche
858 Quando generate una richiesta di *pull*, usate l'etichetta firmata come
892 E-mail di Linus Torvalds sul formato canonico di una patch: