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
111 riferimento. Per esempio, se la vostra patch corregge un baco potete aggiungere
112 quest'etichetta per fare riferimento ad un rapporto su una lista di discussione
113 o un *bug tracker*. Un altro esempio; potete usare quest'etichetta per far
119 servizio d'archiviazione lore.kernel.org. Per create un collegamento URL è
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
148 Se la vostra patch corregge un baco in un commit specifico, per esempio avete
149 trovato un problema usando ``git bisect``, per favore usate l'etichetta
150 'Fixes:' indicando i primi 12 caratteri dell'identificativo SHA-1 seguiti
164 Un esempio::
166 $ git log -1 --pretty=fixes 54a4f0239f2e
172 ----------------------------
176 Per esempio, se i vostri cambiamenti per un singolo driver includono
179 un aggiornamento dell'API e un nuovo driver che lo sfrutta, allora separateli
183 queste modifiche in una singola patch. Dunque, un singolo cambiamento logico
190 Se al fine di ottenere un cambiamento completo una patch dipende da un'altra,
198 della vostra serie in un punto qualsiasi; non vi saranno grati se nel mezzo
207 ---------------------------------------------
210 dettagli sono disponibili in Documentation/translations/it_IT/process/coding-style.rst.
215 Un'eccezione importante si ha quando del codice viene spostato da un file
216 ad un altro -- in questo caso non dovreste modificare il codice spostato
224 di stile dovrebbe essere visto come una guida, non come un sostituto al
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
244 vostre patch). Se non riuscite a trovare un manutentore per il sottosistema su
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
252 lista di discussione dedicata ad un sottosistema; probabilmente lì la vostra
257 vger.kernel.org; potete trovare un loro elenco alla pagina
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.
269 Se avete una patch che corregge un baco di sicurezza che potrebbe essere
270 sfruttato, inviatela a security@kernel.org. Per bachi importanti, un breve
275 Documentation/process/security-bugs.rst.
277 Patch che correggono bachi importanti su un kernel già rilasciato, dovrebbero
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
315 La patch non deve essere un allegato MIME, compresso o meno. Molti
316 dei più popolari programmi di posta elettronica non trasmettono un allegato
318 Inoltre, un allegato MIME rende l'attività di Linus più laboriosa, diminuendo
319 così la possibilità che il vostro allegato-MIME venga accettato.
324 Leggete Documentation/translations/it_IT/process/email-clients.rst
329 -----------------------------------
333 rispondere a questi commenti; ignorare i revisori è un ottimo modo per
335 modifica del codice quasi certamente dovrebbero portare ad un commento
340 ringraziarli per il loro tempo. Revisionare codice è un lavoro faticoso e che
343 evidenziato. Quando inviate una versione successiva ricordatevi di aggiungere un
348 Leggete Documentation/translations/it_IT/process/email-clients.rst per
354 Non scoraggiatevi - o impazientitevi
355 ------------------------------------
361 Un tempo, le patch erano solite scomparire nel vuoto senza alcun commento,
365 rinviare le modifiche o sollecitare i revisori - probabilmente anche di più
368 Potete anche rinviare la patch, o la serie di patch, dopo un paio di settimane
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
411 (b) Il contributo è basato su un lavoro precedente che, nei limiti
412 della mia conoscenza, è coperto da un'appropriata licenza
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
416 un'altra licenza) indicata nel file; oppure
422 contributi sono pubblici e che un registro dei contributi (incluse
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
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
530 (su un qualche sistema) dalla persona citata. Questa etichetta informa i
531 manutentori che qualche verifica è stata fatta, fornisce un mezzo per trovare
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
571 Quando si riceve una email sulla lista di discussione da un tester o
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
580 non dovrebbe essere aggiunta senza un permesso esplicito, specialmente se
581 l'idea non è stata pubblicata in un forum pubblico. Detto ciò, dando credito
585 L'etichetta Fixes: indica che la patch corregge un problema in un commit
586 precedente. Serve a chiarire l'origine di un baco, il che aiuta la revisione
589 Questo è il modo suggerito per indicare che un baco è stato corretto nella
592 Da notare che aggiungere un tag "Fixes:" non esime dalle regole
600 -------------------------------
603 Notate che se state usando un repositorio ``git`` per salvare le vostre patch
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;
641 il contenuto della patch. La ``summary phrase`` non dovrebbe essere un nome
646 Ricordatevi che la ``summary phrase`` della vostra email diventerà un
653 come ``gitk`` o ``git log --oneline``.
657 brevi e descrittivi è una bella sfida, ma questo è quello che fa un riassunto
660 La ``summary phrase`` può avere un'etichetta (*tag*) di prefisso racchiusa fra
674 Un paio di esempi di oggetti::
692 deve aver senso per un lettore esperto che è ha dimenticato i dettagli della
701 Se la patch corregge un errore di compilazione, non sarà necessario
707 La linea di demarcazione ``---`` serve essenzialmente a segnare dove finisce
710 Aggiungere il ``diffstat`` dopo ``---`` è un buon uso di questo spazio, per
712 Un ``diffstat`` è particolarmente utile per le patch grandi. Se
713 includete un ``diffstat`` dopo ``---``, usate le opzioni ``-p 1 -w70``
719 inadatti al changelog permanente, dovrebbero essere messi qui. Un
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+++--
750 che portano ad un problema. Tuttavia, non tutti i *backtrace* sono
757 Quindi, per rendere utile un *backtrace* dovreste eliminare le
759 problema. Ecco un esempio di un *backtrace* essenziale::
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.
778 In questo modo versioni multiple di una patch non diventeranno un'ingestibile
779 giungla di riferimenti all'interno dei programmi di posta. Se un collegamento
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