Lines Matching +full:va +full:- +full:dai +full:- +full:link
1 .. include:: ../disclaimer-ita.rst
3 :Original: :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
19 Documentation/translations/it_IT/process/development-process.rst. Leggete anche
20 Documentation/translations/it_IT/process/submit-checklist.rst per una lista di
23 Documentation/translations/it_IT/process/submitting-patches.rst.
31 :ref:`Documentation/translations/it_IT/process/maintainer-handbooks.rst <it_maintainer_handbooks_ma…
34 ---------------------------
52 ------------------------------
64 la maggior parte delle installazioni Linux usa un kernel che arriva dai
65 sorgenti stabili o dai sorgenti di una distribuzione particolare che prende
66 singolarmente le patch dai sorgenti principali; quindi, includete tutte
110 l'identificativo SHA-1. Per cortesia, aggiungete anche la breve riga
120 dell'identificativo SHA-1. Il repositorio del kernel ha *molti* oggetti e
126 riferimento alla patch, allora aggiungete l'etichetta 'Link:' per farvi
140 sufficiente usare il campo ``Message-Id``, presente nell'intestazione del
143 Link: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/
155 Closes: https://example.com/issues/1234 optional-other-stuff
165 'Fixes:' indicando i primi 12 caratteri dell'identificativo SHA-1 seguiti
181 $ git log -1 --pretty=fixes 54a4f0239f2e
187 ----------------------------
202 che siano facilmente comprensibili e che possano essere verificate dai revisori.
206 va bene. Semplicemente scrivete una nota nella descrizione della patch per
222 ---------------------------------------------
225 dettagli sono disponibili in Documentation/translations/it_IT/process/coding-style.rst.
231 ad un altro -- in questo caso non dovreste modificare il codice spostato
244 - ERROR: le cose sono molto probabilmente sbagliate
245 - WARNING: le cose necessitano d'essere revisionate con attenzione
246 - CHECK: le cose necessitano di un pensierino
253 -----------------------------------------------
261 (akpm@linux-foundation.org) sarà la vostra ultima possibilità.
263 La lista linux-kernel@vger.kernel.org dovrebbe essere usata per l'invio di tutte
270 vostra serie di patch. La lista di discussione linux-kernel@vger.kernel.org
279 http://vger.kernel.org/vger-lists.html. Tuttavia, ci sono altre liste di
285 Linux Torvalds. Il suo indirizzo e-mail è <torvalds@linux-foundation.org>.
286 Riceve moltissime e-mail, e, a questo punto, solo poche patch passano
288 meglio per -evitare di- inviargli e-mail.
296 Documentation/process/security-bugs.rst.
304 delle e-mail). In aggiunta a questo file, dovreste leggere anche
305 Documentation/translations/it_IT/process/stable-kernel-rules.rst.
312 linux-api@vger.kernel.org.
315 -------------------------------------------------------------
323 Per questa ragione tutte le patch devono essere inviate via e-mail
325 send-email``. Al sito https://git-send-email.io è disponibile una
326 guida interattiva sull'uso di ``git send-email``.
328 Se decidete di non usare ``git send-email``:
332 Se decidete di copiare ed incollare la patch nel corpo dell'e-mail, state
340 così la possibilità che il vostro allegato-MIME venga accettato.
345 Leggete Documentation/translations/it_IT/process/email-clients.rst
350 -----------------------------------
370 Leggete Documentation/translations/it_IT/process/email-clients.rst per
377 ------------------------------------------------------
403 Non scoraggiatevi - o impazientitevi
404 ------------------------------------
414 rinviare le modifiche o sollecitare i revisori - probabilmente anche di più
423 della vostra patch, o serie di patch - "RESEND" si applica solo alla
428 -----------------------------
430 Dato l'alto volume di e-mail per Linus, e la lista linux-kernel, è prassi
435 ``git send-email`` lo fa automaticamente.
438 Firmate il vostro lavoro - Il certificato d'origine dello sviluppatore
439 ----------------------------------------------------------------------
444 delle patch che vengono inviate per e-mail.
448 come patch open-source. Le regole sono abbastanza semplici: se potete
457 ho il diritto di inviarlo in accordo con la licenza open-source
462 open-source che mi da il diritto di modificarlo e inviarlo,
464 la licenza open-source (a meno che non abbia il permesso di usare
475 open-source coinvolte.
479 Signed-off-by: Random J Developer <random@developer.example.org>
483 ``git commit -s``. Anche il ripristino di uno stato precedente dovrebbe
484 includere "Signed-off-by", se usate ``git revert -s`` questo verrà
491 In seguito al SoB (Signed-off-by:) dell'autore ve ne sono altri da
499 Quando utilizzare Acked-by:, Cc:, e Co-developed-by:
500 ----------------------------------------------------
502 L'etichetta Signed-off-by: indica che il firmatario è stato coinvolto nello
508 una riga Acked-by:.
510 Acked-by: viene spesso utilizzato dai manutentori del sottosistema in oggetto
513 Acked-by: non è formale come Signed-off-by:. Questo indica che la persona ha
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
528 alcunché - ma dovrebbe indicare che la persona ha ricevuto una copia della
532 Co-developed-by: indica che la patch è stata cosviluppata da diversi
535 che Co-developed-by: implica la paternità della patch, ogni Co-developed-by:
536 dev'essere seguito immediatamente dal Signed-off-by: del corrispondente
537 coautore. Qui si applica la procedura di base per sign-off, in pratica
538 l'ordine delle etichette Signed-off-by: dovrebbe riflettere il più possibile
540 la paternità venga assegnata via From: o Co-developed-by:. Da notare che
541 l'ultimo Signed-off-by: dev'essere quello di colui che ha sottomesso la patch.
551 Co-developed-by: First Co-Author <first@coauthor.example.org>
552 Signed-off-by: First Co-Author <first@coauthor.example.org>
553 Co-developed-by: Second Co-Author <second@coauthor.example.org>
554 Signed-off-by: Second Co-Author <second@coauthor.example.org>
555 Signed-off-by: From Author <from@author.example.org>
557 Esempio di una patch sottomessa dall'autore Co-developed-by:::
563 Co-developed-by: Random Co-Author <random@coauthor.example.org>
564 Signed-off-by: Random Co-Author <random@coauthor.example.org>
565 Signed-off-by: From Author <from@author.example.org>
566 Co-developed-by: Submitting Co-Author <sub@coauthor.example.org>
567 Signed-off-by: Submitting Co-Author <sub@coauthor.example.org>
569 Utilizzare Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: e Fixes:
570 -------------------------------------------------------------------------
572 L'etichetta Reported-by da credito alle persone che trovano e riportano i bachi
575 permesso prima di poter utilizzare l'etichetta Reported-by. Questa etichetta va
578 rapporto, a meno che questo non sia disponibile sul web. L'etichetta Link: può
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
594 Offrendo la mia etichetta Reviewed-by, dichiaro quanto segue:
614 L'etichetta Reviewed-by è la dichiarazione di un parere sulla bontà di
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
625 un revisore, le etichette Tested-by o Reviewed-by devono essere
629 della rimozione nel changelog della patch (subito dopo il separatore '---').
631 L'etichetta Suggested-by: indica che l'idea della patch è stata suggerita
653 -------------------------------
657 potere usare il comando ``git format-patch`` per ottenere patch nel formato
667 - Una riga ``from`` che specifica l'autore della patch, seguita
671 - Il corpo della spiegazione, con linee non più lunghe di 75 caratteri,
674 - Una riga vuota
676 - Le righe ``Signed-off-by:``, descritte in precedenza, che finiranno
679 - Una linea di demarcazione contenente semplicemente ``---``.
681 - Qualsiasi altro commento che non deve finire nel changelog.
683 - Le effettive modifiche al codice (il prodotto di ``diff``).
686 per ordinare le patch alfabeticamente - tutti i programmi di posta hanno
687 questa funzionalità - dato che al numero sequenziale si antepongono degli zeri;
706 come ``gitk`` o ``git log --oneline``.
760 La linea di demarcazione ``---`` serve essenzialmente a segnare dove finisce
763 Aggiungere il ``diffstat`` dopo ``---`` è un buon uso di questo spazio, per
766 includete un ``diffstat`` dopo ``---``, usate le opzioni ``-p 1 -w70``
777 Queste informazioni devono andare **dopo** la linea ``---`` che separa
787 Signed-off-by: Author <author@mail>
788 ---
789 V2 -> V3: Removed redundant helper function
790 V1 -> V2: Cleaned up coding style and addressed review comments
792 path/to/file | 5+++--
823 Usare esplicitamente In-Reply-To nell'intestazione
824 --------------------------------------------------
826 Aggiungere manualmente In-Reply-To: nell'intestazione dell'e-mail
828 precedente, per esempio per collegare la correzione di un baco con l'e-mail
830 sconsigliato l'uso di In-Reply-To: per collegare precedenti versioni.
838 -------------------------------------
850 Se si usa ``git format-patch`` per generare le patch, si possono includere
852 ``--base``. Il modo più semplice e comodo di usare questa opzione è con i rami
855 $ git checkout -t -b my-topical-branch master
856 Branch 'my-topical-branch' set up to track local branch 'master'.
857 Switched to a new branch 'my-topical-branch'
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à
867 che ha ``base-commit:`` in fondo, questo fornisce al revisore e agli
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
882 L'opzione ``--base`` fu introdotta con git versione 2.9.0
885 ``base-commit`` per indicare l'hash del commit dei sorgenti su cui si basa il
887 patch della serie e dovrebbe essere collocato sotto la riga ``---`` o in fondo a
888 tutti gli altri contenuti, subito prima della vostra firma e-mail.
895 -----------
901 <https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html>
903 Greg Kroah-Hartman, "Come scocciare un manutentore di un sottosistema"
906 <http://www.kroah.com/log/linux/maintainer-02.html>
908 <http://www.kroah.com/log/linux/maintainer-03.html>
910 <http://www.kroah.com/log/linux/maintainer-04.html>
912 <http://www.kroah.com/log/linux/maintainer-05.html>
914 <http://www.kroah.com/log/linux/maintainer-06.html>
916 No!!!! Basta gigantesche bombe patch alle persone sulla lista linux-kernel@vger.kernel.org!
919 Kernel Documentation/translations/it_IT/process/coding-style.rst.
921 E-mail di Linus Torvalds sul formato canonico di una patch:
927 http://halobates.de/on-submitting-patches.pdf