Lines Matching refs:patch
8 Inviare patch: la guida essenziale per vedere il vostro codice nel kernel
11 Una persona o un'azienda che volesse inviare una patch al kernel potrebbe
15 vostre patch accettate.
23 per delle patch relative alle associazioni per Device Tree leggete
28 patch molto del lavoro più ripetitivo lo troverete già fatto per voi, tuttavia
29 dovete preparare e documentare un certo numero di patch. Generalmente, l'uso
43 sorgenti e desiderano che le patch siano preparate basandosi su di essi.
55 Se dovete produrre le vostre patch a mano, usate ``diff -up`` o ``diff -uprN``
56 per crearle. Git produce di base le patch in questo formato; se state
59 Tutte le modifiche al kernel Linux avvengono mediate patch, come descritte
60 in :manpage:`diff(1)`. Quando create la vostra patch, assicuratevi di
65 di ``diff`` molto più facile da leggere. Le patch dovrebbero essere basate
68 Per creare una patch per un singolo file, spesso è sufficiente fare::
77 diff -up $SRCTREE/$MYFILE{.orig,} > /tmp/patch
79 Per creare una patch per molteplici file, dovreste spacchettare i sorgenti
88 linux-3.19-vanilla $MYSRC > /tmp/patch
92 patch generata con :manpage:`diff(1)`.
94 Assicuratevi che la vostra patch non includa file che non ne fanno veramente
96 revisionare la vostra patch -dopo- averla generata con :manpage:`diff(1)`.
99 in patch indipendenti che modificano le cose in passi logici; leggete
101 sviluppatori, il che è molto importante se volete che la patch venga accettata.
124 singolarmente le patch dai sorgenti principali; quindi, includete tutte
145 I manutentori vi saranno grati se scrivete la descrizione della patch in un
149 Risolvete solo un problema per patch. Se la vostra descrizione inizia ad
150 essere lunga, potrebbe essere un segno che la vostra patch necessita d'essere
153 Quando inviate o rinviate una patch o una serie, includete la descrizione
155 questa è la versione N della patch (o serie). Non aspettatevi che i
157 cercare la descrizione da aggiungere. In pratica, la patch (o serie) e la sua
160 le versioni precedenti della patch.
163 do frotz" piuttosto che "[This patch] makes xyzzy do frotz" or "[I] changed
167 Se la patch corregge un baco conosciuto, fare riferimento a quel baco inserendo
168 il suo numero o il suo URL. Se la patch è la conseguenza di una discussione
177 portato alla creazione della patch.
195 Se la vostra patch corregge un baco in un commit specifico, per esempio avete
216 Separate ogni **cambiamento logico** in patch distinte.
220 allora separateli in due o più patch. Se i vostri cambiamenti includono
222 in due patch.
225 queste modifiche in una singola patch. Dunque, un singolo cambiamento logico
226 è contenuto in una sola patch.
230 Ogni patch dovrebbe essere giustificabile di per sé.
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
234 farlo presente: **"this patch depends on patch X"**.
236 Quando dividete i vostri cambiamenti in una serie di patch, prestate
237 particolare attenzione alla verifica di ogni patch della serie; per ognuna
243 Se non potete condensare la vostra serie di patch in una più piccola, allora
251 Controllate che la vostra patch non violi lo stile del codice, maggiori
254 voi vedrete la vostra patch rifiutata, probabilmente senza nemmeno essere stata
259 per nessun motivo, almeno non nella patch che lo sposta. Questo separa
264 Prima di inviare una patch, verificatene lo stile usando l'apposito
276 nella vostra patch.
279 5) Selezionate i destinatari della vostra patch
282 Dovreste sempre inviare una copia della patch ai manutentori dei sottosistemi
290 la vostra serie di patch. La lista di discussione linux-kernel@vger.kernel.org
294 patch riceverà molta più attenzione. Tuttavia, per favore, non spammate le
302 Non inviate più di 15 patch alla volta sulle liste di discussione vger!!!
306 Riceve moltissime e-mail, e, a questo punto, solo poche patch passano
310 Se avete una patch che corregge un baco di sicurezza che potrebbe essere
313 distribuzioni di prendere la patch e renderla disponibile ai loro utenti;
314 in questo caso, ovviamente, la patch non dovrebbe essere inviata su alcuna
322 nella vostra patch, nell'area dedicata alle firme (notate, NON come destinatario
327 l'ultima parola su quali patch dovrebbero essere aggiunte ai kernel stabili.
329 sviluppatori aggiungere alle loro patch delle righe come quella sopracitata.
332 inviate una patch per le pagine man ai manutentori di suddette pagine (elencati
338 Per le piccole patch potreste aggiungere in CC l'indirizzo
340 le patch "banali". Date uno sguardo al file MAINTAINERS per vedere chi
343 Le patch banali devono rientrare in una delle seguenti categorie:
354 "patch monkey" in modalità ritrasmissione)
366 Per questa ragione tutte le patch devono essere inviate via e-mail
371 Se decidete di copiare ed incollare la patch nel corpo dell'e-mail, state
375 La patch non deve essere un allegato MIME, compresso o meno. Molti
381 Eccezione: se il vostro servizio di posta storpia le patch, allora qualcuno
386 per l'invio di patch intatte.
392 per alcuni manutentori. Se la vostra patch, non compressa, eccede i 300 kB
394 l'URL (collegamento) ad essa. Ma notate che se la vostra patch eccede i 300 kB
401 la vostra patch. Dovete rispondere a questi commenti; ignorare i revisori
417 I revisori sono persone occupate e potrebbero non ricevere la vostra patch
420 Un tempo, le patch erano solite scomparire nel vuoto senza alcun commento,
423 aver inviato le patch correttamente. Aspettate almeno una settimana prima di
432 altri sviluppatori del kernel di distinguere facilmente le patch dalle altre
440 quelle patch che per raggiungere lo stadio finale passano attraverso
442 delle patch che vengono inviate per e-mail.
444 La firma è una semplice riga alla fine della descrizione della patch che
446 come patch open-source. Le regole sono abbastanza semplici: se potete
487 modificare leggermente le patch che avete ricevuto al fine di poterle
490 regola (c), dovreste chiedere al mittente di rifare la patch, ma questo è
493 la patch di qualcuno e addossargli la responsabilità per i vostri bachi.
513 patch all'inizio del messaggio di commit (appena dopo la riga dell'oggetto)
523 E qui quello che potrebbe vedersi su un kernel più vecchio dove la patch è
541 sviluppo della patch, o che era nel suo percorso di consegna.
544 della patch ma desidera firmare e mettere agli atti la loro approvazione,
545 allora queste persone possono chiedere di aggiungere al changelog della patch
549 quando quello stesso manutentore non ha contribuito né trasmesso la patch.
552 revisionato la patch e l'ha trovata accettabile. Per cui, a volte, chi
553 integra le patch convertirà un "sì, mi sembra che vada bene" in un Acked-by:
556 Acked-by: non indica l'accettazione di un'intera patch. Per esempio, quando
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
564 fatto, potete aggiungere l'etichetta ``Cc:`` alla patch. Questa è l'unica
567 patch. Questa etichetta documenta che terzi potenzialmente interessati sono
570 Co-developed-by: indica che la patch è stata cosviluppata da diversi
572 associato all'etichetta From:) quando più persone lavorano ad una patch. Dato
573 che Co-developed-by: implica la paternità della patch, ogni Co-developed-by:
577 l'ordine cronologico della storia della patch, indipendentemente dal fatto che
579 l'ultimo Signed-off-by: dev'essere quello di colui che ha sottomesso la patch.
585 Esempio di una patch sottomessa dall'autore in From:::
595 Esempio di una patch sottomessa dall'autore Co-developed-by:::
615 L'etichetta Tested-by: indica che la patch è stata verificata con successo
621 Reviewd-by:, invece, indica che la patch è stata revisionata ed è stata
629 (a) Ho effettuato una revisione tecnica di questa patch per valutarne
633 (b) Tutti i problemi e le domande riguardanti la patch sono stati
642 (d) Nonostante abbia revisionato la patch e creda che vada bene,
650 possono offrire il proprio Reviewed-by per la patch. Questa etichetta serve
652 che è stato fatto sulla patch. L'etichetta Reviewd-by, quando fornita da
654 loro serietà nella revisione, accrescerà le probabilità che la vostra patch
657 L'etichetta Suggested-by: indica che l'idea della patch è stata suggerita
664 L'etichetta Fixes: indica che la patch corregge un problema in un commit
669 patch. Per maggiori dettagli leggete :ref:`it_describe_changes`
672 14) Il formato canonico delle patch
675 Questa sezione descrive il formato che dovrebbe essere usato per le patch.
676 Notate che se state usando un repositorio ``git`` per salvare le vostre patch
677 potere usare il comando ``git format-patch`` per ottenere patch nel formato
681 L'oggetto di una patch canonica è la riga::
685 Il corpo di una patch canonica contiene i seguenti elementi:
687 - Una riga ``from`` che specifica l'autore della patch, seguita
689 patch non ne è l'autore).
692 che verrà copiato permanentemente nel changelog per descrivere la patch.
706 per ordinare le patch alfabeticamente - tutti i programmi di posta hanno
711 o il sottosistema modificato dalla patch.
714 il contenuto della patch. La ``summary phrase`` non dovrebbe essere un nome
715 di file. Non utilizzate la stessa ``summary phrase`` per tutte le patch in
716 una serie (dove una ``serie di patch`` è una sequenza ordinata di diverse
717 patch correlate).
720 identificatore globale ed unico per quella patch. Si propaga fino al
722 dagli sviluppatori per riferirsi a quella patch. Le persone vorranno
725 quando, in due o tre mesi, riguarderanno centinaia di patch usando strumenti
736 indicano come la patch dovrebbe essere trattata. Fra le etichette più comuni
737 ci sono quelle di versione che vengono usate quando una patch è stata inviata
739 attendono dei commenti (*Request For Comments*). Se ci sono quattro patch
741 Questo assicura che gli sviluppatori capiranno l'ordine in cui le patch
756 l'autore della patch. Se la riga ``from`` è mancante, allora per determinare
762 discussione che hanno portato alla patch. L'inclusione di informazioni
763 sui problemi oggetto dalla patch (messaggi del kernel, messaggi di oops,
765 i messaggi di log per la patch che li tratta. Se la patch corregge un errore
768 che la vostra patch venga trovata. Come nella ``summary phrase``, è importante
776 Un ``diffstat`` è particolarmente utile per le patch grandi. Altri commenti
780 della patch.
787 Maggiori dettagli sul formato delle patch nei riferimenti qui di seguito.
795 potrebbe essere d'aiuto per associare una patch ad una discussione
797 che lo riportava. Tuttavia, per serie di patch multiple è generalmente
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
810 ``git pull``. Comunque, tenete presente che prendere patch da uno sviluppatore
815 come messaggio introduttivo ad una normale pubblicazione di patch, così
829 che dica cos'è incluso, una lista delle patch usando ``git shortlog``, e una
830 panoramica sugli effetti della serie di patch con ``diffstat``. Il modo più
837 firmata Linus, in particolare, non prenderà alcuna patch da siti pubblici come
847 Una volta che avete preparato la vostra serie di patch in ``git``, e volete che
854 Se i sorgenti da cui il manutentore prenderà le patch non sono gli stessi del
867 Andrew Morton, "La patch perfetta" (tpp).
870 Jeff Garzik, "Formato per la sottomissione di patch per il kernel Linux"
871 <https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html>
886 No!!!! Basta gigantesche bombe patch alle persone sulla lista linux-kernel@vger.kernel.org!
892 E-mail di Linus Torvalds sul formato canonico di una patch:
895 Andi Kleen, "Su come sottomettere patch del kernel"