Lines Matching full: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.
22 Per delle patch relative alle associazioni per Device Tree leggete
25 Questa documentazione assume che sappiate usare ``git`` per preparare le patch.
44 sorgenti e desiderano che le patch siano preparate basandosi su di essi.
66 singolarmente le patch dai sorgenti principali; quindi, includete tutte
87 I manutentori vi saranno grati se scrivete la descrizione della patch in un
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
95 Quando inviate o rinviate una patch o una serie, includete la descrizione
97 questa è la versione N della patch (o serie). Non aspettatevi che i
99 cercare la descrizione da aggiungere. In pratica, la patch (o serie) e la sua
102 le versioni precedenti della patch.
105 do frotz" piuttosto che "[This patch] makes xyzzy do frotz" or "[I] changed
126 riferimento alla patch, allora aggiungete l'etichetta 'Link:' per farvi
127 riferimento. Se la patch è il risultato di una discussione avvenuta
131 Per esempio, se la vostra patch corregge un baco potete aggiungere
135 discussione, o qualcosa di documentato sul web, da cui poi è nata la patch in
150 condotto all'invio della patch.
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
189 Separate ogni **cambiamento logico** in patch distinte.
193 allora separateli in due o più patch. Se i vostri cambiamenti includono
195 in due patch.
198 queste modifiche in una singola patch. Dunque, un singolo cambiamento logico
199 è contenuto in una sola patch.
203 Ogni patch dovrebbe essere giustificabile di per sé.
205 Se al fine di ottenere un cambiamento completo una patch dipende da un'altra,
206 va bene. Semplicemente scrivete una nota nella descrizione della patch per
207 farlo presente: **"this patch depends on patch X"**.
209 Quando dividete i vostri cambiamenti in una serie di patch, prestate
210 particolare attenzione alla verifica di ogni patch della serie; per ognuna
216 Se non potete condensare la vostra serie di patch in una più piccola, allora
224 Controllate che la vostra patch non violi lo stile del codice, maggiori
227 voi vedrete la vostra patch rifiutata, probabilmente senza nemmeno essere stata
232 per nessun motivo, almeno non nella patch che lo sposta. Questo separa
237 Prima di inviare una patch, verificatene lo stile usando l'apposito
249 nella vostra patch.
252 5) Selezionate i destinatari della vostra patch
255 Dovreste sempre inviare una copia della patch ai manutentori e alle liste di
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
270 vostra serie di patch. La lista di discussione linux-kernel@vger.kernel.org
271 dovrebbe essere usata per inviare tutte le patch, ma il traffico è tale per cui
274 patch riceverà molta più attenzione. Tuttavia, per favore, non spammate le liste
282 Non inviate più di 15 patch alla volta sulle liste di discussione vger!!!
286 Riceve moltissime e-mail, e, a questo punto, solo poche patch passano
290 Se avete una patch che corregge un baco di sicurezza che potrebbe essere
293 distribuzioni di prendere la patch e renderla disponibile ai loro utenti;
294 in questo caso, ovviamente, la patch non dovrebbe essere inviata su alcuna
298 Patch che correggono bachi importanti su un kernel già rilasciato, dovrebbero
303 nella vostra patch, nell'area dedicata alle firme (notate, NON come destinatario
308 inviate una patch per le pagine man ai manutentori di suddette pagine (elencati
323 Per questa ragione tutte le patch devono essere inviate via e-mail
332 Se decidete di copiare ed incollare la patch nel corpo dell'e-mail, state
336 La patch non deve essere un allegato MIME, compresso o meno. Molti
342 Eccezione: se il vostro servizio di posta storpia le patch, allora qualcuno
347 per l'invio di patch intatte.
353 invieranno dei commenti su come migliorare la vostra patch. Dovete
365 ``patch changelog`` alla email di intestazione o ad ogni singola patch spiegando
407 I revisori sono persone occupate e potrebbero non ricevere la vostra patch
410 Un tempo, le patch erano solite scomparire nel vuoto senza alcun commento, ma
413 aver inviato le patch correttamente. Aspettate almeno una settimana prima di
417 Potete anche rinviare la patch, o la serie di patch, dopo un paio di settimane
420 [PATCH Vx RESEND] sub/sys: Condensed patch summary
423 della vostra patch, o serie di patch - "RESEND" si applica solo alla
424 sottomissione di patch, o serie di patch, che non hanno subito modifiche
427 Aggiungete PATCH nell'oggetto
431 prefiggere il vostro oggetto con [PATCH]. Questo permette a Linus e agli
432 altri sviluppatori del kernel di distinguere facilmente le patch dalle altre
442 quelle patch che per raggiungere lo stadio finale passano attraverso
444 delle patch che vengono inviate per e-mail.
446 La firma è una semplice riga alla fine della descrizione della patch che
448 come patch open-source. Le regole sono abbastanza semplici: se potete
493 del trasporto della patch. Queste però non sono state coinvolte nello
495 **reale** che una patch a intrapreso dallo sviluppatore, fino al
503 sviluppo della patch, o che era nel suo percorso di consegna.
506 della patch ma desidera firmare e mettere agli atti la loro approvazione,
507 allora queste persone possono chiedere di aggiungere al changelog della patch
511 quando quello stesso manutentore non ha contribuito né trasmesso la patch.
514 revisionato la patch e l'ha trovata accettabile. Per cui, a volte, chi
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
525 Se una persona ha avuto l'opportunità di commentare la patch, ma non lo ha
526 fatto, potete aggiungere l'etichetta ``Cc:`` alla patch. Questa è l'unica
529 patch. Questa etichetta documenta che terzi potenzialmente interessati sono
532 Co-developed-by: indica che la patch è stata cosviluppata da diversi
534 associato all'etichetta From:) quando più persone lavorano ad una patch. Dato
535 che Co-developed-by: implica la paternità della patch, ogni Co-developed-by:
539 l'ordine cronologico della storia della patch, indipendentemente dal fatto che
541 l'ultimo Signed-off-by: dev'essere quello di colui che ha sottomesso la patch.
547 Esempio di una patch sottomessa dall'autore in From:::
557 Esempio di una patch sottomessa dall'autore Co-developed-by:::
579 essere usata in alternativa a Closes: se la patch corregge solo in parte il
582 L'etichetta Tested-by: indica che la patch è stata verificata con successo
588 Reviewed-by:, invece, indica che la patch è stata revisionata ed è stata
596 (a) Ho effettuato una revisione tecnica di questa patch per valutarne
600 (b) Tutti i problemi e le domande riguardanti la patch sono stati
609 (d) Nonostante abbia revisionato la patch e creda che vada bene,
617 possono offrire il proprio Reviewed-by per la patch. Questa etichetta serve
619 che è stato fatto sulla patch. L'etichetta Reviewed-by, quando fornita da
621 loro serietà nella revisione, accrescerà le probabilità che la vostra patch
626 aggiunte dall'autore quando invierà nuovamente la patch. Tuttavia, se
627 la patch è cambiata in modo significativo, queste etichette potrebbero
629 della rimozione nel changelog della patch (subito dopo il separatore '---').
631 L'etichetta Suggested-by: indica che l'idea della patch è stata suggerita
638 L'etichetta Fixes: indica che la patch corregge un problema in un commit
643 patch. Per maggiori dettagli leggete :ref:`it_describe_changes`
647 in copia conoscenza stable@vger.kernel.org su tutte le patch per
652 Il formato canonico delle patch
655 Questa sezione descrive il formato che dovrebbe essere usato per le patch.
656 Notate che se state usando un repositorio ``git`` per salvare le vostre patch
657 potere usare il comando ``git format-patch`` per ottenere patch nel formato
661 L'oggetto di una patch canonica è la riga::
663 Subject: [PATCH 001/123] subsystem: summary phrase
665 Il corpo di una patch canonica contiene i seguenti elementi:
667 - Una riga ``from`` che specifica l'autore della patch, seguita
669 patch non ne è l'autore).
672 che verrà copiato permanentemente nel changelog per descrivere la patch.
686 per ordinare le patch alfabeticamente - tutti i programmi di posta hanno
691 o il sottosistema modificato dalla patch.
694 il contenuto della patch. La ``summary phrase`` non dovrebbe essere un nome
695 di file. Non utilizzate la stessa ``summary phrase`` per tutte le patch in
696 una serie (dove una ``serie di patch`` è una sequenza ordinata di diverse
697 patch correlate).
700 identificatore globale ed unico per quella patch. Si propaga fino al
702 dagli sviluppatori per riferirsi a quella patch. Le persone vorranno
705 quando, in due o tre mesi, riguarderanno centinaia di patch usando strumenti
714 le parentesi quadre "Subject: [PATCH <tag>...] <summary phrase>".
716 indicano come la patch dovrebbe essere trattata. Fra le etichette più comuni
717 ci sono quelle di versione che vengono usate quando una patch è stata inviata
721 Se ci sono quattro patch nella serie, queste dovrebbero essere
723 sviluppatori capiranno l'ordine in cui le patch dovrebbero essere
729 Subject: [PATCH 2/5] ext2: improve scalability of bitmap searching
730 Subject: [PATCH v2 01/27] x86: fix eflags tracking
731 Subject: [PATCH v2] sub/sys: Condensed patch summary
732 Subject: [PATCH v2 M/N] sub/sys: Condensed patch summary
737 From: Patch Author <author@example.com>
740 l'autore della patch. Se la riga ``from`` è mancante, allora per determinare
746 discussione che hanno portato alla patch. L'inclusione di informazioni
747 sui problemi oggetto dalla patch (messaggi del kernel, messaggi di oops,
749 i messaggi di log per la patch che li tratta. Il testo dovrebbe essere scritto
751 patch fu creata, e questo a distanza di settimane, mesi, o addirittura
754 Se la patch corregge un errore di compilazione, non sarà necessario
756 aggiungete solo quello che è necessario per far si che la vostra patch
765 Un ``diffstat`` è particolarmente utile per le patch grandi. Se
774 ``patch changelogs`` che descrivere le differenze fra le versioni
775 della patch.
778 il *changelog* dal resto della patch. Le informazioni riguardanti la
779 versione di una patch non sono parte del *chagelog* che viene incluso
795 Maggiori dettagli sul formato delle patch nei riferimenti qui di seguito.
827 potrebbe essere d'aiuto per associare una patch ad una discussione
829 che lo riportava. Tuttavia, per serie di patch multiple è generalmente
831 In questo modo versioni multiple di una patch non diventeranno un'ingestibile
834 ad una versione precedente di una serie di patch (per esempio, potete usarlo
840 Quando gli altri sviluppatori ricevono le vostre patch e iniziano il processo di
850 Se si usa ``git format-patch`` per generare le patch, si possono includere
861 $ git format-patch --base=auto --cover-letter -o outgoing/ master
862 outgoing/0000-cover-letter.patch
863 outgoing/0001-First-Commit.patch
866 Aprendo ``outgoing/0000-cover-letter.patch`` per la modifica, si noterà
871 $ git checkout -b patch-review [base-commit-id]
872 Switched to a new branch 'patch-review'
877 Consultate ``man git-format-patch`` per maggiori informazioni circa questa
884 Se non si usa git per produrre le patch, si può comunque includere
887 patch della serie e dovrebbe essere collocato sotto la riga ``---`` o in fondo a
897 Andrew Morton, "La patch perfetta" (tpp).
900 Jeff Garzik, "Formato per la sottomissione di patch per il kernel Linux"
901 <https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html>
916 No!!!! Basta gigantesche bombe patch alle persone sulla lista linux-kernel@vger.kernel.org!
921 E-mail di Linus Torvalds sul formato canonico di una patch:
924 Andi Kleen, "Su come sottomettere patch del kernel"