Lines Matching +full:e +full:- +full:mail
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.
29 I sorgenti di alcuni sottosistemi e manutentori contengono più informazioni
31 :ref:`Documentation/translations/it_IT/process/maintainer-handbooks.rst <it_maintainer_handbooks_ma…
34 ---------------------------
44 sorgenti e desiderano che le patch siano preparate basandosi su di essi.
52 ------------------------------
57 la pena risolvere il vostro problema e che ha senso continuare a leggere oltre
61 e blocchi sono abbastanza convincenti, ma non tutti i bachi sono così evidenti.
72 Quantificare le ottimizzazioni e i compromessi. Se affermate di aver
77 un compromesso fra l'uso di CPU, la memoria e la leggibilità; o, quando si
80 valutare i costi e i benefici.
96 completa delle modifiche e la loro giustificazione. Non limitatevi a dire che
99 cercare la descrizione da aggiungere. In pratica, la patch (o serie) e la sua
100 descrizione devono essere un'unica cosa. Questo aiuta i manutentori e i
120 sufficiente usare il campo ``Message-Id``, presente nell'intestazione del
126 creato funzioni e che indirizzi verso il messaggio desiderato.
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 ----------------------------
179 un aggiornamento dell'API e un nuovo driver che lo sfrutta, allora separateli
187 che siano facilmente comprensibili e che possano essere verificate dai revisori.
202 pubblicatene una quindicina alla volta e aspettate che vengano revisionate
207 ---------------------------------------------
210 dettagli sono disponibili in Documentation/translations/it_IT/process/coding-style.rst.
211 Non farlo porta semplicemente a una perdita di tempo da parte dei revisori e
216 ad un altro -- in questo caso non dovreste modificare il codice spostato
218 chiaramente l'azione di spostare il codice e il vostro cambiamento.
219 Questo aiuta enormemente la revisione delle vere differenze e permette agli
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 -----------------------------------------------
241 interessati dalle modifiche; date un'occhiata al file MAINTAINERS e alla storia
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.
272 distribuzioni di prendere la patch e renderla disponibile ai loro utenti;
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 -------------------------------------------------------------
296 Linus e gli altri sviluppatori del kernel devono poter commentare
302 Per questa ragione tutte le patch devono essere inviate via e-mail
303 come testo. Il modo più facile, e quello raccomandato, è con ``git
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
317 MIME come puro testo, e questo rende impossibile commentare il vostro codice.
319 così la possibilità che il vostro allegato-MIME venga accettato.
324 Leggete Documentation/translations/it_IT/process/email-clients.rst
329 -----------------------------------
339 Assicuratevi di dire ai revisori quali cambiamenti state facendo e di
340 ringraziarli per il loro tempo. Revisionare codice è un lavoro faticoso e che
341 richiede molto tempo, e a volte i revisori diventano burberi. Tuttavia, anche in
342 questo caso, rispondete con educazione e concentratevi sul problema che hanno
348 Leggete Documentation/translations/it_IT/process/email-clients.rst per
349 le raccomandazioni sui programmi di posta elettronica e l'etichetta da usare
354 Non scoraggiatevi - o impazientitevi
355 ------------------------------------
357 Dopo che avete inviato le vostre modifiche, siate pazienti e aspettate.
358 I revisori sono persone occupate e potrebbero non ricevere la vostra patch
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
382 prefiggere il vostro oggetto con [PATCH]. Questo permette a Linus e agli
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
407 (a) Il contributo è stato creato interamente, o in parte, da me e che
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
419 ha certificato (a), (b) o (c) e non l'ho modificata.
421 (d) Capisco e concordo col fatto che questo progetto e i suoi
422 contributi sono pubblici e che un registro dei contributi (incluse
424 firma) verrà mantenuto indefinitamente e che possa essere
426 open-source coinvolte.
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
443 parte di tutte quelle persone che si sono occupate della gestione e
450 Quando utilizzare Acked-by:, Cc:, e Co-developed-by:
451 ----------------------------------------------------
453 L'etichetta Signed-off-by: indica che il firmatario è stato coinvolto nello
457 della patch ma desidera firmare e mettere agli atti la loro approvazione,
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
465 revisionato la patch e l'ha trovata accettabile. Per cui, a volte, chi
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.
495 anche la persona (e indirizzo email) indicato nel From: dell'intestazione
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
524 e si spera che questo possa ispirarli ad aiutarci nuovamente in futuro.
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
532 persone che possano verificare il codice in futuro, e garantisce che queste
535 Reviewed-by:, invece, indica che la patch è stata revisionata ed è stata
541 Offrendo la mia etichetta Reviewed-by, dichiaro quanto segue:
547 (b) Tutti i problemi e le domande riguardanti la patch sono stati
553 di interesse per il kernel, e (2) libera da problemi che
556 (d) Nonostante abbia revisionato la patch e creda che vada bene,
561 L'etichetta Reviewed-by è la dichiarazione di un parere sulla bontà di
562 una modifica che si ritiene appropriata e senza alcun problema tecnico
564 possono offrire il proprio Reviewed-by per la patch. Questa etichetta serve
565 a dare credito ai revisori e a informare i manutentori sul livello di revisione
566 che è stato fatto sulla patch. L'etichetta Reviewed-by, quando fornita da
567 revisori conosciuti per la loro conoscenza sulla materia in oggetto e per la
572 un revisore, le etichette Tested-by o Reviewed-by devono essere
575 non avere più senso e quindi andrebbero rimosse. Solitamente si tiene traccia
576 della rimozione nel changelog della patch (subito dopo il separatore '---').
578 L'etichetta Suggested-by: indica che l'idea della patch è stata suggerita
579 dalla persona nominata e le da credito. Tenete a mente che questa etichetta
593 previste per i kernel stabili, e nemmeno dalla necessità di aggiungere
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``.
655 Per queste ragioni, dovrebbe essere lunga fra i 70 e i 75 caratteri, e deve
657 brevi e descrittivi è una bella sfida, ma questo è quello che fa un riassunto
671 applicate, e per tracciare quelle che hanno revisionate o che hanno
698 patch fu creata, e questo a distanza di settimane, mesi, o addirittura
707 La linea di demarcazione ``---`` serve essenzialmente a segnare dove finisce
710 Aggiungere il ``diffstat`` dopo ``---`` è un buon uso di questo spazio, per
711 mostrare i file che sono cambiati, e il numero di file aggiunto o rimossi.
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+++--
752 e ovvie. Copiare integralmente l'output di ``dmesg`` aggiunge tante
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