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
110 riferimento alla patch, allora aggiungete l'etichetta 'Link:' per farvi
111 riferimento. Per esempio, se la vostra patch corregge un baco potete aggiungere
115 discussione, o qualcosa di documentato sul web, da cui poi è nata la patch in
130 condotto all'invio della patch.
148 Se la vostra patch corregge un baco in un commit specifico, per esempio avete
174 Separate ogni **cambiamento logico** in patch distinte.
178 allora separateli in due o più patch. Se i vostri cambiamenti includono
180 in due patch.
183 queste modifiche in una singola patch. Dunque, un singolo cambiamento logico
184 è contenuto in una sola patch.
188 Ogni patch dovrebbe essere giustificabile di per sé.
190 Se al fine di ottenere un cambiamento completo una patch dipende da un'altra,
191 va bene. Semplicemente scrivete una nota nella descrizione della patch per
192 farlo presente: **"this patch depends on patch X"**.
194 Quando dividete i vostri cambiamenti in una serie di patch, prestate
195 particolare attenzione alla verifica di ogni patch della serie; per ognuna
201 Se non potete condensare la vostra serie di patch in una più piccola, allora
209 Controllate che la vostra patch non violi lo stile del codice, maggiori
212 voi vedrete la vostra patch rifiutata, probabilmente senza nemmeno essere stata
217 per nessun motivo, almeno non nella patch che lo sposta. Questo separa
222 Prima di inviare una patch, verificatene lo stile usando l'apposito
234 nella vostra patch.
237 5) Selezionate i destinatari della vostra patch
240 Dovreste sempre inviare una copia della patch ai manutentori dei sottosistemi
244 vostre patch). Se non riuscite a trovare un manutentore per il sottosistema su
249 vostra serie di patch. La lista di discussione linux-kernel@vger.kernel.org
250 dovrebbe essere usata per inviare tutte le patch, ma il traffico è tale per cui
253 patch riceverà molta più attenzione. Tuttavia, per favore, non spammate le liste
261 Non inviate più di 15 patch alla volta sulle liste di discussione vger!!!
265 Riceve moltissime e-mail, e, a questo punto, solo poche patch passano
269 Se avete una patch che corregge un baco di sicurezza che potrebbe essere
272 distribuzioni di prendere la patch e renderla disponibile ai loro utenti;
273 in questo caso, ovviamente, la patch non dovrebbe essere inviata su alcuna
277 Patch che correggono bachi importanti su un kernel già rilasciato, dovrebbero
282 nella vostra patch, nell'area dedicata alle firme (notate, NON come destinatario
287 inviate una patch per le pagine man ai manutentori di suddette pagine (elencati
302 Per questa ragione tutte le patch devono essere inviate via e-mail
311 Se decidete di copiare ed incollare la patch nel corpo dell'e-mail, state
315 La patch non deve essere un allegato MIME, compresso o meno. Molti
321 Eccezione: se il vostro servizio di posta storpia le patch, allora qualcuno
326 per l'invio di patch intatte.
332 invieranno dei commenti su come migliorare la vostra patch. Dovete
344 ``patch changelog`` alla email di intestazione o ad ogni singola patch spiegando
358 I revisori sono persone occupate e potrebbero non ricevere la vostra patch
361 Un tempo, le patch erano solite scomparire nel vuoto senza alcun commento,
364 aver inviato le patch correttamente. Aspettate almeno una settimana prima di
368 Potete anche rinviare la patch, o la serie di patch, dopo un paio di settimane
371 [PATCH Vx RESEND] sub/sys: Condensed patch summary
374 della vostra patch, o serie di patch - "RESEND" si applica solo alla
375 sottomissione di patch, o serie di patch, che non hanno subito modifiche
378 Aggiungete PATCH nell'oggetto
382 prefiggere il vostro oggetto con [PATCH]. Questo permette a Linus e agli
383 altri sviluppatori del kernel di distinguere facilmente le patch dalle altre
393 quelle patch che per raggiungere lo stadio finale passano attraverso
395 delle patch che vengono inviate per e-mail.
397 La firma è una semplice riga alla fine della descrizione della patch che
399 come patch open-source. Le regole sono abbastanza semplici: se potete
444 del trasporto della patch. Queste però non sono state coinvolte nello
446 **reale** che una patch a intrapreso dallo sviluppatore, fino al
454 sviluppo della patch, o che era nel suo percorso di consegna.
457 della patch ma desidera firmare e mettere agli atti la loro approvazione,
458 allora queste persone possono chiedere di aggiungere al changelog della patch
462 quando quello stesso manutentore non ha contribuito né trasmesso la patch.
465 revisionato la patch e l'ha trovata accettabile. Per cui, a volte, chi
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
476 Se una persona ha avuto l'opportunità di commentare la patch, ma non lo ha
477 fatto, potete aggiungere l'etichetta ``Cc:`` alla patch. Questa è l'unica
480 patch. Questa etichetta documenta che terzi potenzialmente interessati sono
483 Co-developed-by: indica che la patch è stata cosviluppata da diversi
485 associato all'etichetta From:) quando più persone lavorano ad una patch. Dato
486 che Co-developed-by: implica la paternità della patch, ogni Co-developed-by:
490 l'ordine cronologico della storia della patch, indipendentemente dal fatto che
492 l'ultimo Signed-off-by: dev'essere quello di colui che ha sottomesso la patch.
498 Esempio di una patch sottomessa dall'autore in From:::
508 Esempio di una patch sottomessa dall'autore Co-developed-by:::
529 L'etichetta Tested-by: indica che la patch è stata verificata con successo
535 Reviewd-by:, invece, indica che la patch è stata revisionata ed è stata
543 (a) Ho effettuato una revisione tecnica di questa patch per valutarne
547 (b) Tutti i problemi e le domande riguardanti la patch sono stati
556 (d) Nonostante abbia revisionato la patch e creda che vada bene,
564 possono offrire il proprio Reviewed-by per la patch. Questa etichetta serve
566 che è stato fatto sulla patch. L'etichetta Reviewd-by, quando fornita da
568 loro serietà nella revisione, accrescerà le probabilità che la vostra patch
573 aggiunte dall'autore quando invierà nuovamente la patch. Tuttavia, se
574 la patch è cambiata in modo significativo, queste etichette potrebbero
576 della rimozione nel changelog della patch (subito dopo il separatore '---').
578 L'etichetta Suggested-by: indica che l'idea della patch è stata suggerita
585 L'etichetta Fixes: indica che la patch corregge un problema in un commit
590 patch. Per maggiori dettagli leggete :ref:`it_describe_changes`
594 in copia conoscenza stable@vger.kernel.org su tutte le patch per
599 Il formato canonico delle patch
602 Questa sezione descrive il formato che dovrebbe essere usato per le patch.
603 Notate che se state usando un repositorio ``git`` per salvare le vostre patch
604 potere usare il comando ``git format-patch`` per ottenere patch nel formato
608 L'oggetto di una patch canonica è la riga::
610 Subject: [PATCH 001/123] subsystem: summary phrase
612 Il corpo di una patch canonica contiene i seguenti elementi:
614 - Una riga ``from`` che specifica l'autore della patch, seguita
616 patch non ne è l'autore).
619 che verrà copiato permanentemente nel changelog per descrivere la patch.
633 per ordinare le patch alfabeticamente - tutti i programmi di posta hanno
638 o il sottosistema modificato dalla patch.
641 il contenuto della patch. La ``summary phrase`` non dovrebbe essere un nome
642 di file. Non utilizzate la stessa ``summary phrase`` per tutte le patch in
643 una serie (dove una ``serie di patch`` è una sequenza ordinata di diverse
644 patch correlate).
647 identificatore globale ed unico per quella patch. Si propaga fino al
649 dagli sviluppatori per riferirsi a quella patch. Le persone vorranno
652 quando, in due o tre mesi, riguarderanno centinaia di patch usando strumenti
661 le parentesi quadre "Subject: [PATCH <tag>...] <summary phrase>".
663 indicano come la patch dovrebbe essere trattata. Fra le etichette più comuni
664 ci sono quelle di versione che vengono usate quando una patch è stata inviata
668 Se ci sono quattro patch nella serie, queste dovrebbero essere
670 sviluppatori capiranno l'ordine in cui le patch dovrebbero essere
676 Subject: [PATCH 2/5] ext2: improve scalability of bitmap searching
677 Subject: [PATCH v2 01/27] x86: fix eflags tracking
678 Subject: [PATCH v2] sub/sys: Condensed patch summary
679 Subject: [PATCH v2 M/N] sub/sys: Condensed patch summary
684 From: Patch Author <author@example.com>
687 l'autore della patch. Se la riga ``from`` è mancante, allora per determinare
693 discussione che hanno portato alla patch. L'inclusione di informazioni
694 sui problemi oggetto dalla patch (messaggi del kernel, messaggi di oops,
696 i messaggi di log per la patch che li tratta. Il testo dovrebbe essere scritto
698 patch fu creata, e questo a distanza di settimane, mesi, o addirittura
701 Se la patch corregge un errore di compilazione, non sarà necessario
703 aggiungete solo quello che è necessario per far si che la vostra patch
712 Un ``diffstat`` è particolarmente utile per le patch grandi. Se
721 ``patch changelogs`` che descrivere le differenze fra le versioni
722 della patch.
725 il *changelog* dal resto della patch. Le informazioni riguardanti la
726 versione di una patch non sono parte del *chagelog* che viene incluso
742 Maggiori dettagli sul formato delle patch nei riferimenti qui di seguito.
774 potrebbe essere d'aiuto per associare una patch ad una discussione
776 che lo riportava. Tuttavia, per serie di patch multiple è generalmente
778 In questo modo versioni multiple di una patch non diventeranno un'ingestibile
781 ad una versione precedente di una serie di patch (per esempio, potete usarlo
787 Andrew Morton, "La patch perfetta" (tpp).
790 Jeff Garzik, "Formato per la sottomissione di patch per il kernel Linux"
791 <https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html>
806 No!!!! Basta gigantesche bombe patch alle persone sulla lista linux-kernel@vger.kernel.org!
811 E-mail di Linus Torvalds sul formato canonico di una patch:
814 Andi Kleen, "Su come sottomettere patch del kernel"