Lines Matching +full:open +full:- +full:dice
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 ------------------------------
120 sufficiente usare il campo ``Message-Id``, presente nell'intestazione del
133 l'identificativo SHA-1. Per cortesia, aggiungete anche la breve riga
143 dell'identificativo SHA-1. Il repositorio del kernel ha *molti* oggetti e
150 'Fixes:' indicando i primi 12 caratteri dell'identificativo SHA-1 seguiti
166 $ git log -1 --pretty=fixes 54a4f0239f2e
172 ----------------------------
207 ---------------------------------------------
210 dettagli sono disponibili in Documentation/translations/it_IT/process/coding-style.rst.
216 ad un altro -- in questo caso non dovreste modificare il codice spostato
229 - ERROR: le cose sono molto probabilmente sbagliate
230 - WARNING: le cose necessitano d'essere revisionate con attenzione
231 - CHECK: le cose necessitano di un pensierino
238 -----------------------------------------------
245 cui state lavorando, allora Andrew Morton (akpm@linux-foundation.org) sarà la
249 vostra serie di patch. La lista di discussione linux-kernel@vger.kernel.org
258 http://vger.kernel.org/vger-lists.html. Tuttavia, ci sono altre liste di
264 Linux Torvalds. Il suo indirizzo e-mail è <torvalds@linux-foundation.org>.
265 Riceve moltissime e-mail, e, a questo punto, solo poche patch passano
267 meglio per -evitare di- inviargli e-mail.
275 Documentation/process/security-bugs.rst.
283 delle e-mail). In aggiunta a questo file, dovreste leggere anche
284 Documentation/translations/it_IT/process/stable-kernel-rules.rst.
291 linux-api@vger.kernel.org.
294 -------------------------------------------------------------
302 Per questa ragione tutte le patch devono essere inviate via e-mail
304 send-email``. Al sito https://git-send-email.io è disponibile una
305 guida interattiva sull'uso di ``git send-email``.
307 Se decidete di non usare ``git send-email``:
311 Se decidete di copiare ed incollare la patch nel corpo dell'e-mail, state
319 così la possibilità che il vostro allegato-MIME venga accettato.
324 Leggete Documentation/translations/it_IT/process/email-clients.rst
329 -----------------------------------
348 Leggete Documentation/translations/it_IT/process/email-clients.rst per
354 Non scoraggiatevi - o impazientitevi
355 ------------------------------------
365 rinviare le modifiche o sollecitare i revisori - probabilmente anche di più
374 della vostra patch, o serie di patch - "RESEND" si applica solo alla
379 -----------------------------
381 Dato l'alto volume di e-mail per Linus, e la lista linux-kernel, è prassi
386 ``git send-email`` lo fa automaticamente.
389 Firmate il vostro lavoro - Il certificato d'origine dello sviluppatore
390 ----------------------------------------------------------------------
395 delle patch che vengono inviate per e-mail.
399 come patch open-source. Le regole sono abbastanza semplici: se potete
408 ho il diritto di inviarlo in accordo con la licenza open-source
413 open-source che mi da il diritto di modificarlo e inviarlo,
415 la licenza open-source (a meno che non abbia il permesso di usare
426 open-source coinvolte.
428 poi dovete solo aggiungere una riga che dice::
430 Signed-off-by: Random J Developer <random@developer.example.org>
434 ``git commit -s``. Anche il ripristino di uno stato precedente dovrebbe
435 includere "Signed-off-by", se usate ``git revert -s`` questo verrà
442 In seguito al SoB (Signed-off-by:) dell'autore ve ne sono altri da
450 Quando utilizzare Acked-by:, Cc:, e Co-developed-by:
451 ----------------------------------------------------
453 L'etichetta Signed-off-by: indica che il firmatario è stato coinvolto nello
459 una riga Acked-by:.
461 Acked-by: viene spesso utilizzato dai manutentori del sottosistema in oggetto
464 Acked-by: non è formale come Signed-off-by:. Questo indica che la persona ha
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
479 alcunché - ma dovrebbe indicare che la persona ha ricevuto una copia della
483 Co-developed-by: indica che la patch è stata cosviluppata da diversi
486 che Co-developed-by: implica la paternità della patch, ogni Co-developed-by:
487 dev'essere seguito immediatamente dal Signed-off-by: del corrispondente
488 coautore. Qui si applica la procedura di base per sign-off, in pratica
489 l'ordine delle etichette Signed-off-by: dovrebbe riflettere il più possibile
491 la paternità venga assegnata via From: o Co-developed-by:. Da notare che
492 l'ultimo Signed-off-by: dev'essere quello di colui che ha sottomesso la patch.
502 Co-developed-by: First Co-Author <first@coauthor.example.org>
503 Signed-off-by: First Co-Author <first@coauthor.example.org>
504 Co-developed-by: Second Co-Author <second@coauthor.example.org>
505 Signed-off-by: Second Co-Author <second@coauthor.example.org>
506 Signed-off-by: From Author <from@author.example.org>
508 Esempio di una patch sottomessa dall'autore Co-developed-by:::
514 Co-developed-by: Random Co-Author <random@coauthor.example.org>
515 Signed-off-by: Random Co-Author <random@coauthor.example.org>
516 Signed-off-by: From Author <from@author.example.org>
517 Co-developed-by: Submitting Co-Author <sub@coauthor.example.org>
518 Signed-off-by: Submitting Co-Author <sub@coauthor.example.org>
520 Utilizzare Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: e Fixes:
521 -------------------------------------------------------------------------
523 L'etichetta Reported-by da credito alle persone che trovano e riportano i bachi
526 permesso prima di poter utilizzare l'etichetta Reported-by. Questa etichetta va
529 L'etichetta Tested-by: indica che la patch è stata verificata con successo
535 Reviewed-by:, invece, indica che la patch è stata revisionata ed è stata
541 Offrendo la mia etichetta Reviewed-by, dichiaro quanto segue:
561 L'etichetta Reviewed-by è la dichiarazione di un parere sulla bontà di
564 possono offrire il proprio Reviewed-by per la patch. Questa etichetta serve
566 che è stato fatto sulla patch. L'etichetta Reviewed-by, quando fornita da
572 un revisore, le etichette Tested-by o Reviewed-by devono essere
576 della rimozione nel changelog della patch (subito dopo il separatore '---').
578 L'etichetta Suggested-by: indica che l'idea della patch è stata suggerita
600 -------------------------------
604 potere usare il comando ``git format-patch`` per ottenere patch nel formato
614 - Una riga ``from`` che specifica l'autore della patch, seguita
618 - Il corpo della spiegazione, con linee non più lunghe di 75 caratteri,
621 - Una riga vuota
623 - Le righe ``Signed-off-by:``, descritte in precedenza, che finiranno
626 - Una linea di demarcazione contenente semplicemente ``---``.
628 - Qualsiasi altro commento che non deve finire nel changelog.
630 - Le effettive modifiche al codice (il prodotto di ``diff``).
633 per ordinare le patch alfabeticamente - tutti i programmi di posta hanno
634 questa funzionalità - dato che al numero sequenziale si antepongono degli zeri;
653 come ``gitk`` o ``git log --oneline``.
707 La linea di demarcazione ``---`` serve essenzialmente a segnare dove finisce
710 Aggiungere il ``diffstat`` dopo ``---`` è un buon uso di questo spazio, per
713 includete un ``diffstat`` dopo ``---``, usate le opzioni ``-p 1 -w70``
724 Queste informazioni devono andare **dopo** la linea ``---`` che separa
734 Signed-off-by: Author <author@mail>
735 ---
736 V2 -> V3: Removed redundant helper function
737 V1 -> V2: Cleaned up coding style and addressed review comments
739 path/to/file | 5+++--
770 Usare esplicitamente In-Reply-To nell'intestazione
771 --------------------------------------------------
773 Aggiungere manualmente In-Reply-To: nell'intestazione dell'e-mail
775 precedente, per esempio per collegare la correzione di un baco con l'e-mail
777 sconsigliato l'uso di In-Reply-To: per collegare precedenti versioni.
785 -----------
791 <https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html>
793 Greg Kroah-Hartman, "Come scocciare un manutentore di un sottosistema"
796 <http://www.kroah.com/log/linux/maintainer-02.html>
798 <http://www.kroah.com/log/linux/maintainer-03.html>
800 <http://www.kroah.com/log/linux/maintainer-04.html>
802 <http://www.kroah.com/log/linux/maintainer-05.html>
804 <http://www.kroah.com/log/linux/maintainer-06.html>
806 No!!!! Basta gigantesche bombe patch alle persone sulla lista linux-kernel@vger.kernel.org!
809 Kernel Documentation/translations/it_IT/process/coding-style.rst.
811 E-mail di Linus Torvalds sul formato canonico di una patch:
817 http://halobates.de/on-submitting-patches.pdf