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/[email protected]
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-[email protected] dovrebbe essere usata per l'invio di tutte
270 vostra serie di patch. La lista di discussione linux-[email protected]
283 Linux Torvalds. Il suo indirizzo e-mail è <torvalds@linux-foundation.org>.
284 Riceve moltissime e-mail, e, a questo punto, solo poche patch passano
286 meglio per -evitare di- inviargli e-mail.
294 Documentation/process/security-bugs.rst.
302 delle e-mail). In aggiunta a questo file, dovreste leggere anche
303 Documentation/translations/it_IT/process/stable-kernel-rules.rst.
310 linux-[email protected].
313 -------------------------------------------------------------
321 Per questa ragione tutte le patch devono essere inviate via e-mail
323 send-email``. Al sito https://git-send-email.io è disponibile una
324 guida interattiva sull'uso di ``git send-email``.
326 Se decidete di non usare ``git send-email``:
330 Se decidete di copiare ed incollare la patch nel corpo dell'e-mail, state
338 così la possibilità che il vostro allegato-MIME venga accettato.
343 Leggete Documentation/translations/it_IT/process/email-clients.rst
348 -----------------------------------
368 Leggete Documentation/translations/it_IT/process/email-clients.rst per
375 ------------------------------------------------------
401 Non scoraggiatevi - o impazientitevi
402 ------------------------------------
412 rinviare le modifiche o sollecitare i revisori - probabilmente anche di più
421 della vostra patch, o serie di patch - "RESEND" si applica solo alla
426 -----------------------------
428 Dato l'alto volume di e-mail per Linus, e la lista linux-kernel, è prassi
433 ``git send-email`` lo fa automaticamente.
436 Firmate il vostro lavoro - Il certificato d'origine dello sviluppatore
437 ----------------------------------------------------------------------
442 delle patch che vengono inviate per e-mail.
446 come patch open-source. Le regole sono abbastanza semplici: se potete
455 ho il diritto di inviarlo in accordo con la licenza open-source
460 open-source che mi da il diritto di modificarlo e inviarlo,
462 la licenza open-source (a meno che non abbia il permesso di usare
473 open-source coinvolte.
477 Signed-off-by: Random J Developer <[email protected]>
481 ``git commit -s``. Anche il ripristino di uno stato precedente dovrebbe
482 includere "Signed-off-by", se usate ``git revert -s`` questo verrà
489 In seguito al SoB (Signed-off-by:) dell'autore ve ne sono altri da
497 Quando utilizzare Acked-by:, Cc:, e Co-developed-by:
498 ----------------------------------------------------
500 L'etichetta Signed-off-by: indica che il firmatario è stato coinvolto nello
506 una riga Acked-by:.
508 Acked-by: viene spesso utilizzato dai manutentori del sottosistema in oggetto
511 Acked-by: non è formale come Signed-off-by:. Questo indica che la persona ha
513 integra le patch convertirà un "sì, mi sembra che vada bene" in un Acked-by:
516 Acked-by: non indica l'accettazione di un'intera patch. Per esempio, quando
517 una patch ha effetti su diversi sottosistemi e ha un Acked-by: da un
526 alcunché - ma dovrebbe indicare che la persona ha ricevuto una copia della
530 Co-developed-by: indica che la patch è stata cosviluppata da diversi
533 che Co-developed-by: implica la paternità della patch, ogni Co-developed-by:
534 dev'essere seguito immediatamente dal Signed-off-by: del corrispondente
535 coautore. Qui si applica la procedura di base per sign-off, in pratica
536 l'ordine delle etichette Signed-off-by: dovrebbe riflettere il più possibile
538 la paternità venga assegnata via From: o Co-developed-by:. Da notare che
539 l'ultimo Signed-off-by: dev'essere quello di colui che ha sottomesso la patch.
549 Co-developed-by: First Co-Author <[email protected]>
550 Signed-off-by: First Co-Author <[email protected]>
551 Co-developed-by: Second Co-Author <[email protected]>
552 Signed-off-by: Second Co-Author <[email protected]>
553 Signed-off-by: From Author <[email protected]>
555 Esempio di una patch sottomessa dall'autore Co-developed-by:::
561 Co-developed-by: Random Co-Author <[email protected]>
562 Signed-off-by: Random Co-Author <[email protected]>
563 Signed-off-by: From Author <[email protected]>
564 Co-developed-by: Submitting Co-Author <[email protected]>
565 Signed-off-by: Submitting Co-Author <[email protected]>
567 Utilizzare Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: e Fixes:
568 -------------------------------------------------------------------------
570 L'etichetta Reported-by da credito alle persone che trovano e riportano i bachi
573 permesso prima di poter utilizzare l'etichetta Reported-by. Questa etichetta va
576 rapporto, a meno che questo non sia disponibile sul web. L'etichetta Link: può
580 L'etichetta Tested-by: indica che la patch è stata verificata con successo
586 Reviewed-by:, invece, indica che la patch è stata revisionata ed è stata
592 Offrendo la mia etichetta Reviewed-by, dichiaro quanto segue:
612 L'etichetta Reviewed-by è la dichiarazione di un parere sulla bontà di
615 possono offrire il proprio Reviewed-by per la patch. Questa etichetta serve
617 che è stato fatto sulla patch. L'etichetta Reviewed-by, quando fornita da
623 un revisore, le etichette Tested-by o Reviewed-by devono essere
627 della rimozione nel changelog della patch (subito dopo il separatore '---').
629 L'etichetta Suggested-by: indica che l'idea della patch è stata suggerita
651 -------------------------------
655 potere usare il comando ``git format-patch`` per ottenere patch nel formato
665 - Una riga ``from`` che specifica l'autore della patch, seguita
669 - Il corpo della spiegazione, con linee non più lunghe di 75 caratteri,
672 - Una riga vuota
674 - Le righe ``Signed-off-by:``, descritte in precedenza, che finiranno
677 - Una linea di demarcazione contenente semplicemente ``---``.
679 - Qualsiasi altro commento che non deve finire nel changelog.
681 - Le effettive modifiche al codice (il prodotto di ``diff``).
684 per ordinare le patch alfabeticamente - tutti i programmi di posta hanno
685 questa funzionalità - dato che al numero sequenziale si antepongono degli zeri;
704 come ``gitk`` o ``git log --oneline``.
758 La linea di demarcazione ``---`` serve essenzialmente a segnare dove finisce
761 Aggiungere il ``diffstat`` dopo ``---`` è un buon uso di questo spazio, per
764 includete un ``diffstat`` dopo ``---``, usate le opzioni ``-p 1 -w70``
775 Queste informazioni devono andare **dopo** la linea ``---`` che separa
785 Signed-off-by: Author <author@mail>
786 ---
787 V2 -> V3: Removed redundant helper function
788 V1 -> V2: Cleaned up coding style and addressed review comments
790 path/to/file | 5+++--
821 Usare esplicitamente In-Reply-To nell'intestazione
822 --------------------------------------------------
824 Aggiungere manualmente In-Reply-To: nell'intestazione dell'e-mail
826 precedente, per esempio per collegare la correzione di un baco con l'e-mail
828 sconsigliato l'uso di In-Reply-To: per collegare precedenti versioni.
836 -------------------------------------
848 Se si usa ``git format-patch`` per generare le patch, si possono includere
850 ``--base``. Il modo più semplice e comodo di usare questa opzione è con i rami
853 $ git checkout -t -b my-topical-branch master
854 Branch 'my-topical-branch' set up to track local branch 'master'.
855 Switched to a new branch 'my-topical-branch'
859 $ git format-patch --base=auto --cover-letter -o outgoing/ master
860 outgoing/0000-cover-letter.patch
861 outgoing/0001-First-Commit.patch
864 Aprendo ``outgoing/0000-cover-letter.patch`` per la modifica, si noterà
865 che ha ``base-commit:`` in fondo, questo fornisce al revisore e agli
869 $ git checkout -b patch-review [base-commit-id]
870 Switched to a new branch 'patch-review'
875 Consultate ``man git-format-patch`` per maggiori informazioni circa questa
880 L'opzione ``--base`` fu introdotta con git versione 2.9.0
883 ``base-commit`` per indicare l'hash del commit dei sorgenti su cui si basa il
885 patch della serie e dovrebbe essere collocato sotto la riga ``---`` o in fondo a
886 tutti gli altri contenuti, subito prima della vostra firma e-mail.
893 ---------
901 -----------
907 <https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html>
909 Greg Kroah-Hartman, "Come scocciare un manutentore di un sottosistema"
912 <http://www.kroah.com/log/linux/maintainer-02.html>
914 <http://www.kroah.com/log/linux/maintainer-03.html>
916 <http://www.kroah.com/log/linux/maintainer-04.html>
918 <http://www.kroah.com/log/linux/maintainer-05.html>
920 <http://www.kroah.com/log/linux/maintainer-06.html>
922 Kernel Documentation/translations/it_IT/process/coding-style.rst.
924 E-mail di Linus Torvalds sul formato canonico di una patch:
930 http://halobates.de/on-submitting-patches.pdf