Lines Matching +full:un +full:-
1 .. include:: ../disclaimer-ita.rst
3 :Original: :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
11 Una persona o un'azienda che volesse inviare una patch al kernel potrebbe
17 Questo documento contiene un vasto numero di suggerimenti concisi. Per maggiori
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 ---------------------------
36 Se non avete un repositorio coi sorgenti del kernel più recenti, allora usate
45 Guardate l'elemento **T:** per un determinato sottosistema nel file MAINTANERS
52 ------------------------------
54 Descrivete il vostro problema. Esiste sempre un problema che via ha spinto
55 ha fare il vostro lavoro, che sia la correzione di un baco da una riga o una
64 la maggior parte delle installazioni Linux usa un kernel che arriva dai
69 un incidente di sistema, prestazioni di una regressione, picchi di latenza,
77 un compromesso fra l'uso di CPU, la memoria e la leggibilità; o, quando si
84 in un inglese semplice cosicché i revisori possano verificare che il codice si
87 I manutentori vi saranno grati se scrivete la descrizione della patch in un
89 ``git``, come un "commit log". Leggete :ref:`it_the_canonical_patch_format`.
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
98 manutentori di un sottosistema vadano a cercare le versioni precedenti per
100 descrizione devono essere un'unica cosa. Questo aiuta i manutentori e i
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
128 precedentemente o di un documento sul presente sul web, allora fatevi
131 Per esempio, se la vostra patch corregge un baco potete aggiungere
132 quest'etichetta per fare riferimento ad un rapporto su una lista di discussione
133 o un *bug tracker*. Un altro esempio; potete usare quest'etichetta per far
139 servizio d'archiviazione lore.kernel.org. Per create un collegamento URL è
140 sufficiente usare il campo ``Message-Id``, presente nell'intestazione del
152 Se il collegamento indirizza verso un rapporto su un baco risolto dalla patch,
155 Closes: https://example.com/issues/1234 optional-other-stuff
163 Se la vostra patch corregge un baco in un commit specifico, per esempio avete
164 trovato un problema usando ``git bisect``, per favore usate l'etichetta
165 'Fixes:' indicando i primi 12 caratteri dell'identificativo SHA-1 seguiti
179 Un esempio::
181 $ git log -1 --pretty=fixes 54a4f0239f2e
187 ----------------------------
191 Per esempio, se i vostri cambiamenti per un singolo driver includono
194 un aggiornamento dell'API e un nuovo driver che lo sfrutta, allora separateli
198 queste modifiche in una singola patch. Dunque, un singolo cambiamento logico
205 Se al fine di ottenere un cambiamento completo una patch dipende da un'altra,
213 della vostra serie in un punto qualsiasi; non vi saranno grati se nel mezzo
222 ---------------------------------------------
225 dettagli sono disponibili in Documentation/translations/it_IT/process/coding-style.rst.
230 Un'eccezione importante si ha quando del codice viene spostato da un file
231 ad un altro -- in questo caso non dovreste modificare il codice spostato
239 di stile dovrebbe essere visto come una guida, non come un sostituto al
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 -----------------------------------------------
256 discussione dei sottosistemi interessati dalle modifiche; date un'occhiata al
259 percorso alle vostre patch). Se non riuscite a trovare un manutentore per il
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
264 le patch, ma il volume ha raggiunto un livello tale d'aver spinto alcuni
270 vostra serie di patch. La lista di discussione linux-kernel@vger.kernel.org
273 lista di discussione dedicata ad un sottosistema; probabilmente lì la vostra
278 vger.kernel.org; potete trovare un loro elenco alla pagina
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.
290 Se avete una patch che corregge un baco di sicurezza che potrebbe essere
291 sfruttato, inviatela a security@kernel.org. Per bachi importanti, un breve
296 Documentation/process/security-bugs.rst.
298 Patch che correggono bachi importanti su un kernel già rilasciato, dovrebbero
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
336 La patch non deve essere un allegato MIME, compresso o meno. Molti
337 dei più popolari programmi di posta elettronica non trasmettono un allegato
339 Inoltre, un allegato MIME rende l'attività di Linus più laboriosa, diminuendo
340 così la possibilità che il vostro allegato-MIME venga accettato.
345 Leggete Documentation/translations/it_IT/process/email-clients.rst
350 -----------------------------------
354 rispondere a questi commenti; ignorare i revisori è un ottimo modo per
356 modifica del codice quasi certamente dovrebbero portare ad un commento
361 ringraziarli per il loro tempo. Revisionare codice è un lavoro faticoso e che
364 evidenziato. Quando inviate una versione successiva ricordatevi di aggiungere un
370 Leggete Documentation/translations/it_IT/process/email-clients.rst per
377 ------------------------------------------------------
388 R: Perché incasina il normale ordine con cui si legge un testo.
399 D: Dovrei includere un blocco di citazione dopo la mia risposta?
403 Non scoraggiatevi - o impazientitevi
404 ------------------------------------
410 Un tempo, le patch erano solite scomparire nel vuoto senza alcun commento, ma
414 rinviare le modifiche o sollecitare i revisori - probabilmente anche di più
417 Potete anche rinviare la patch, o la serie di patch, dopo un paio di settimane
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
460 (b) Il contributo è basato su un lavoro precedente che, nei limiti
461 della mia conoscenza, è coperto da un'appropriata licenza
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
465 un'altra licenza) indicata nel file; oppure
471 contributi sono pubblici e che un registro dei contributi (incluse
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
577 Questa etichetta dovrebbe essere seguita da quella Closes: con un indirizzo al
582 L'etichetta Tested-by: indica che la patch è stata verificata con successo
583 (su un qualche sistema) dalla persona citata. Questa etichetta informa i
584 manutentori che qualche verifica è stata fatta, fornisce un mezzo per trovare
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
624 Quando si riceve una email sulla lista di discussione da un tester o
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
633 non dovrebbe essere aggiunta senza un permesso esplicito, specialmente se
634 l'idea non è stata pubblicata in un forum pubblico. Detto ciò, dando credito
638 L'etichetta Fixes: indica che la patch corregge un problema in un commit
639 precedente. Serve a chiarire l'origine di un baco, il che aiuta la revisione
642 Questo è il modo suggerito per indicare che un baco è stato corretto nella
645 Da notare che aggiungere un tag "Fixes:" non esime dalle regole
653 -------------------------------
656 Notate che se state usando un repositorio ``git`` per salvare le vostre patch
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;
694 il contenuto della patch. La ``summary phrase`` non dovrebbe essere un nome
699 Ricordatevi che la ``summary phrase`` della vostra email diventerà un
706 come ``gitk`` o ``git log --oneline``.
710 brevi e descrittivi è una bella sfida, ma questo è quello che fa un riassunto
713 La ``summary phrase`` può avere un'etichetta (*tag*) di prefisso racchiusa fra
727 Un paio di esempi di oggetti::
745 deve aver senso per un lettore esperto che è ha dimenticato i dettagli della
754 Se la patch corregge un errore di compilazione, non sarà necessario
760 La linea di demarcazione ``---`` serve essenzialmente a segnare dove finisce
763 Aggiungere il ``diffstat`` dopo ``---`` è un buon uso di questo spazio, per
765 Un ``diffstat`` è particolarmente utile per le patch grandi. Se
766 includete un ``diffstat`` dopo ``---``, usate le opzioni ``-p 1 -w70``
772 inadatti al changelog permanente, dovrebbero essere messi qui. Un
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+++--
803 che portano ad un problema. Tuttavia, non tutti i *backtrace* sono
810 Quindi, per rendere utile un *backtrace* dovreste eliminare le
812 problema. Ecco un esempio di un *backtrace* essenziale::
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.
831 In questo modo versioni multiple di una patch non diventeranno un'ingestibile
832 giungla di riferimenti all'interno dei programmi di posta. Se un collegamento
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