diff options
Diffstat (limited to 'Documentation/translations/it_IT/process/submitting-patches.rst')
| -rw-r--r-- | Documentation/translations/it_IT/process/submitting-patches.rst | 158 |
1 files changed, 122 insertions, 36 deletions
diff --git a/Documentation/translations/it_IT/process/submitting-patches.rst b/Documentation/translations/it_IT/process/submitting-patches.rst index 4c6a276bdc08..1cc4808139ce 100644 --- a/Documentation/translations/it_IT/process/submitting-patches.rst +++ b/Documentation/translations/it_IT/process/submitting-patches.rst @@ -106,9 +106,29 @@ do frotz" piuttosto che "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy to do frotz", come se steste dando ordini al codice di cambiare il suo comportamento. +Se volete far riferimento a uno specifico commit, non usate solo +l'identificativo SHA-1. Per cortesia, aggiungete anche la breve riga +riassuntiva del commit per rendere la chiaro ai revisori l'oggetto. +Per esempio:: + + Commit e21d2170f36602ae2708 ("video: remove unnecessary + platform_set_drvdata()") removed the unnecessary + platform_set_drvdata(), but left the variable "dev" unused, + delete it. + +Dovreste anche assicurarvi di usare almeno i primi 12 caratteri +dell'identificativo SHA-1. Il repositorio del kernel ha *molti* oggetti e +questo rende possibile la collisione fra due identificativi con pochi +caratteri. Tenete ben presente che anche se oggi non ci sono collisioni con il +vostro identificativo a 6 caratteri, potrebbero essercene fra 5 anni da oggi. + Se ci sono delle discussioni, o altre informazioni d'interesse, che fanno riferimento alla patch, allora aggiungete l'etichetta 'Link:' per farvi -riferimento. Per esempio, se la vostra patch corregge un baco potete aggiungere +riferimento. Se la patch è il risultato di una discussione avvenuta +precedentemente o di un documento sul presente sul web, allora fatevi +riferimento. + +Per esempio, se la vostra patch corregge un baco potete aggiungere quest'etichetta per fare riferimento ad un rapporto su una lista di discussione o un *bug tracker*. Un altro esempio; potete usare quest'etichetta per far riferimento ad una discussione precedentemente avvenuta su una lista di @@ -117,10 +137,10 @@ questione. Quando volete fare riferimento ad una lista di discussione, preferite il servizio d'archiviazione lore.kernel.org. Per create un collegamento URL è -sufficiente usare il campo ``Message-Id``, presente nell'intestazione del +sufficiente usare il campo ``Message-ID``, presente nell'intestazione del messaggio, senza parentesi angolari. Per esempio:: - Link: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/ + Link: https://lore.kernel.org/30th.anniversary.repost@klaava.Helsinki.FI Prima d'inviare il messaggio ricordatevi di verificare che il collegamento così creato funzioni e che indirizzi verso il messaggio desiderato. @@ -129,21 +149,16 @@ Tuttavia, provate comunque a dare una spiegazione comprensibile anche senza accedere alle fonti esterne. Inoltre, riassumente i punti più salienti che hanno condotto all'invio della patch. -Se volete far riferimento a uno specifico commit, non usate solo -l'identificativo SHA-1. Per cortesia, aggiungete anche la breve riga -riassuntiva del commit per rendere la chiaro ai revisori l'oggetto. -Per esempio:: +Se il collegamento indirizza verso un rapporto su un baco risolto dalla patch, +allora usate l'etichetta "Closes:":: - Commit e21d2170f36602ae2708 ("video: remove unnecessary - platform_set_drvdata()") removed the unnecessary - platform_set_drvdata(), but left the variable "dev" unused, - delete it. + Closes: https://example.com/issues/1234 optional-other-stuff -Dovreste anche assicurarvi di usare almeno i primi 12 caratteri -dell'identificativo SHA-1. Il repositorio del kernel ha *molti* oggetti e -questo rende possibile la collisione fra due identificativi con pochi -caratteri. Tenete ben presente che anche se oggi non ci sono collisioni con il -vostro identificativo a 6 caratteri, potrebbero essercene fra 5 anni da oggi. +Alcune piattaforme di tracciamento di bachi hanno la capacità di chiudere +automaticamente il problema se l'etichetta è presente nel messaggio. Alcuni +automatismi che monitorano la liste di discussione possono anche tracciare +queste etichette e intraprendere azioni. Piattaforme private e URL invalidi sono +proibiti. Se la vostra patch corregge un baco in un commit specifico, per esempio avete trovato un problema usando ``git bisect``, per favore usate l'etichetta @@ -237,13 +252,19 @@ nella vostra patch. 5) Selezionate i destinatari della vostra patch ----------------------------------------------- -Dovreste sempre inviare una copia della patch ai manutentori dei sottosistemi -interessati dalle modifiche; date un'occhiata al file MAINTAINERS e alla storia -delle revisioni per scoprire chi si occupa del codice. Lo script -scripts/get_maintainer.pl può esservi d'aiuto (passategli il percorso alle -vostre patch). Se non riuscite a trovare un manutentore per il sottosistema su -cui state lavorando, allora Andrew Morton (akpm@linux-foundation.org) sarà la -vostra ultima possibilità. +Dovreste sempre inviare una copia della patch ai manutentori e alle liste di +discussione dei sottosistemi interessati dalle modifiche; date un'occhiata al +file MAINTAINERS e alla storia delle revisioni per scoprire chi si occupa del +codice. Lo script scripts/get_maintainer.pl può esservi d'aiuto (passategli il +percorso alle vostre patch). Se non riuscite a trovare un manutentore per il +sottosistema su cui state lavorando, allora Andrew Morton +(akpm@linux-foundation.org) sarà la vostra ultima possibilità. + +La lista linux-kernel@vger.kernel.org dovrebbe essere usata per l'invio di tutte +le patch, ma il volume ha raggiunto un livello tale d'aver spinto alcuni +sviluppatori a non seguirla più. Dunque, per favore, evitate di inviare messaggi +scorrelati al tema della lista o a persone che non dovrebbero essere +interessate all'argomento. Normalmente, dovreste anche scegliere una lista di discussione a cui inviare la vostra serie di patch. La lista di discussione linux-kernel@vger.kernel.org @@ -254,11 +275,9 @@ patch riceverà molta più attenzione. Tuttavia, per favore, non spammate le lis di discussione che non sono interessate al vostro lavoro. Molte delle liste di discussione relative al kernel vengono ospitate su -vger.kernel.org; potete trovare un loro elenco alla pagina -http://vger.kernel.org/vger-lists.html. Tuttavia, ci sono altre liste di -discussione ospitate altrove. - -Non inviate più di 15 patch alla volta sulle liste di discussione vger!!! +kernel.org; potete trovare un loro elenco alla pagina +https://subspace.kernel.org. Tuttavia, ci sono altre liste di discussione +ospitate altrove. L'ultimo giudizio sull'integrazione delle modifiche accettate spetta a Linux Torvalds. Il suo indirizzo e-mail è <torvalds@linux-foundation.org>. @@ -343,7 +362,8 @@ questo caso, rispondete con educazione e concentratevi sul problema che hanno evidenziato. Quando inviate una versione successiva ricordatevi di aggiungere un ``patch changelog`` alla email di intestazione o ad ogni singola patch spiegando le differenze rispetto a sottomissioni precedenti (vedere -:ref:`it_the_canonical_patch_format`). +:ref:`it_the_canonical_patch_format`). Aggiungete a CC tutte le persone che +vi hanno fornito dei commenti per notificarle di eventuali nuove versioni. Leggete Documentation/translations/it_IT/process/email-clients.rst per le raccomandazioni sui programmi di posta elettronica e l'etichetta da usare @@ -385,10 +405,10 @@ Dopo che avete inviato le vostre modifiche, siate pazienti e aspettate. I revisori sono persone occupate e potrebbero non ricevere la vostra patch immediatamente. -Un tempo, le patch erano solite scomparire nel vuoto senza alcun commento, -ma ora il processo di sviluppo funziona meglio. Dovreste ricevere commenti -in una settimana o poco più; se questo non dovesse accadere, assicuratevi di -aver inviato le patch correttamente. Aspettate almeno una settimana prima di +Un tempo, le patch erano solite scomparire nel vuoto senza alcun commento, ma +ora il processo di sviluppo funziona meglio. Dovreste ricevere commenti in poche +settimane (tipicamente 2 o 3); se questo non dovesse accadere, assicuratevi di +aver inviato le patch correttamente. Aspettate almeno una settimana prima di rinviare le modifiche o sollecitare i revisori - probabilmente anche di più durante la finestra d'integrazione. @@ -552,6 +572,10 @@ e si spera che questo possa ispirarli ad aiutarci nuovamente in futuro. Rammentate che se il baco è stato riportato in privato, dovrete chiedere il permesso prima di poter utilizzare l'etichetta Reported-by. Questa etichetta va usata per i bachi, dunque non usatela per richieste di nuove funzionalità. +Questa etichetta dovrebbe essere seguita da quella Closes: con un indirizzo al +rapporto, a meno che questo non sia disponibile sul web. L'etichetta Link: può +essere usata in alternativa a Closes: se la patch corregge solo in parte il +problema riportato nel rapporto. L'etichetta Tested-by: indica che la patch è stata verificata con successo (su un qualche sistema) dalla persona citata. Questa etichetta informa i @@ -808,6 +832,71 @@ giungla di riferimenti all'interno dei programmi di posta. Se un collegamento ad una versione precedente di una serie di patch (per esempio, potete usarlo per l'email introduttiva alla serie). +Fornire informazioni circa i sorgenti +------------------------------------- + +Quando gli altri sviluppatori ricevono le vostre patch e iniziano il processo di +revisione, è assolutamente necessario che sappiano qual è il commit/ramo di base +su cui si base il vostro lavoro: considerate l'enorme quantità di sorgenti dei +manutentori presenti al giorno d'oggi. Si noti ancora una volta la voce **T:** +nel file MAINTAINERS spiegato sopra. + +Questo è ancora più importante per i processi automatizzati di CI che tentano di +eseguire una serie di test per stabilire la qualità del codice prima che il +manutentore inizi la revisione. + +Se si usa ``git format-patch`` per generare le patch, si possono includere +automaticamente le informazioni sull'albero di base nell'invio usando il flag +``--base``. Il modo più semplice e comodo di usare questa opzione è con i rami +topici:: + + $ git checkout -t -b my-topical-branch master + Branch 'my-topical-branch' set up to track local branch 'master'. + Switched to a new branch 'my-topical-branch' + + [perform your edits and commits] + + $ git format-patch --base=auto --cover-letter -o outgoing/ master + outgoing/0000-cover-letter.patch + outgoing/0001-First-Commit.patch + outgoing/... + +Aprendo ``outgoing/0000-cover-letter.patch`` per la modifica, si noterà +che ha ``base-commit:`` in fondo, questo fornisce al revisore e agli +strumenti CI informazioni sufficienti per eseguire correttamente ``git am`` +senza preoccuparsi dei conflitti:: + + $ git checkout -b patch-review [base-commit-id] + Switched to a new branch 'patch-review' + $ git am patches.mbox + Applying: First Commit + Applying: ... + +Consultate ``man git-format-patch`` per maggiori informazioni circa questa +opzione. + +.. note:: + + L'opzione ``--base`` fu introdotta con git versione 2.9.0 + +Se non si usa git per produrre le patch, si può comunque includere +``base-commit`` per indicare l'hash del commit dei sorgenti su cui si basa il +lavoro. Dovreste aggiungerlo nella lettera di accompagnamento o nella prima +patch della serie e dovrebbe essere collocato sotto la riga ``---`` o in fondo a +tutti gli altri contenuti, subito prima della vostra firma e-mail. + +Assicuratevi che il commit si basi su sorgenti ufficiali del +manutentore/mainline e non su sorgenti interni, accessibile solo a voi, +altrimenti sarebbe inutile. + +Strumenti +--------- + +Molti degli aspetti più tecnici di questo processo possono essere automatizzati +usando b4, la cui documentazione è disponibile all'indirizzo +<https://b4.docs.kernel.org/en/latest/>. Può aiutare a tracciare la dipendenze, +eseguire checkpatch e con la formattazione e l'invio di messaggi di posta. + Riferimenti ----------- @@ -830,9 +919,6 @@ Greg Kroah-Hartman, "Come scocciare un manutentore di un sottosistema" <http://www.kroah.com/log/linux/maintainer-06.html> -No!!!! Basta gigantesche bombe patch alle persone sulla lista linux-kernel@vger.kernel.org! - <https://lore.kernel.org/r/20050711.125305.08322243.davem@davemloft.net> - Kernel Documentation/translations/it_IT/process/coding-style.rst. E-mail di Linus Torvalds sul formato canonico di una patch: |