€•{Œsphinx.addnodes”Œdocument”“”)”}”(Œ rawsource”Œ”Œchildren”]”(Œ translations”Œ LanguagesNode”“”)”}”(hhh]”(hŒ pending_xref”“”)”}”(hhh]”Œdocutils.nodes”ŒText”“”ŒEnglish”…””}”Œparent”hsbaŒ attributes”}”(Œids”]”Œclasses”]”Œnames”]”Œdupnames”]”Œbackrefs”]”Œ refdomain”Œstd”Œreftype”Œdoc”Œ reftarget”Œ/process/5.Posting”Œmodname”NŒ classname”NŒ refexplicit”ˆuŒtagname”hhh ubh)”}”(hhh]”hŒChinese (Simplified)”…””}”hh2sbah}”(h]”h ]”h"]”h$]”h&]”Œ refdomain”h)Œreftype”h+Œ reftarget”Œ%/translations/zh_CN/process/5.Posting”Œmodname”NŒ classname”NŒ refexplicit”ˆuh1hhh ubh)”}”(hhh]”hŒChinese (Traditional)”…””}”hhFsbah}”(h]”h ]”h"]”h$]”h&]”Œ refdomain”h)Œreftype”h+Œ reftarget”Œ%/translations/zh_TW/process/5.Posting”Œmodname”NŒ classname”NŒ refexplicit”ˆuh1hhh ubh)”}”(hhh]”hŒJapanese”…””}”hhZsbah}”(h]”h ]”h"]”h$]”h&]”Œ refdomain”h)Œreftype”h+Œ reftarget”Œ%/translations/ja_JP/process/5.Posting”Œmodname”NŒ classname”NŒ refexplicit”ˆuh1hhh ubh)”}”(hhh]”hŒKorean”…””}”hhnsbah}”(h]”h ]”h"]”h$]”h&]”Œ refdomain”h)Œreftype”h+Œ reftarget”Œ%/translations/ko_KR/process/5.Posting”Œmodname”NŒ classname”NŒ refexplicit”ˆuh1hhh ubh)”}”(hhh]”hŒPortuguese (Brazilian)”…””}”hh‚sbah}”(h]”h ]”h"]”h$]”h&]”Œ refdomain”h)Œreftype”h+Œ reftarget”Œ%/translations/pt_BR/process/5.Posting”Œmodname”NŒ classname”NŒ refexplicit”ˆuh1hhh ubh)”}”(hhh]”hŒSpanish”…””}”hh–sbah}”(h]”h ]”h"]”h$]”h&]”Œ refdomain”h)Œreftype”h+Œ reftarget”Œ%/translations/sp_SP/process/5.Posting”Œmodname”NŒ classname”NŒ refexplicit”ˆuh1hhh ubeh}”(h]”h ]”h"]”h$]”h&]”Œcurrent_language”ŒItalian”uh1h hhŒ _document”hŒsource”NŒline”NubhŒwarning”“”)”}”(hŒ×In caso di dubbi sulla correttezza del contenuto di questa traduzione, l'unico riferimento valido è la documentazione ufficiale in inglese. Per maggiori informazioni consultate le :ref:`avvertenze `.”h]”hŒ paragraph”“”)”}”(hŒ×In caso di dubbi sulla correttezza del contenuto di questa traduzione, l'unico riferimento valido è la documentazione ufficiale in inglese. Per maggiori informazioni consultate le :ref:`avvertenze `.”h]”(hŒ·In caso di dubbi sulla correttezza del contenuto di questa traduzione, l’unico riferimento valido è la documentazione ufficiale in inglese. Per maggiori informazioni consultate le ”…””}”(hh½h²hh³Nh´Nubh)”}”(hŒ!:ref:`avvertenze `”h]”hŒinline”“”)”}”(hhÇh]”hŒ avvertenze”…””}”(hhËh²hh³Nh´Nubah}”(h]”h ]”(Œxref”Œstd”Œstd-ref”eh"]”h$]”h&]”uh1hÉhhÅubah}”(h]”h ]”h"]”h$]”h&]”Œrefdoc”Œ$translations/it_IT/process/5.Posting”Œ refdomain”hÖŒreftype”Œref”Œ refexplicit”ˆŒrefwarn”ˆŒ reftarget”Œ it_disclaimer”uh1hh³Œ3Documentation/translations/it_IT/disclaimer-ita.rst”h´Khh½ubhŒ.”…””}”(hh½h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1h»h³hêh´Khh·ubah}”(h]”h ]”h"]”h$]”h&]”uh1hµhhh²hh³hêh´NubhŒ field_list”“”)”}”(hhh]”(hŒfield”“”)”}”(hhh]”(hŒ field_name”“”)”}”(hŒOriginal”h]”hŒOriginal”…””}”(hjh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jhjh³ŒR/var/lib/git/docbuild/linux/Documentation/translations/it_IT/process/5.Posting.rst”h´KubhŒ field_body”“”)”}”(hŒ@:ref:`Documentation/process/5.Posting.rst `”h]”h¼)”}”(hjh]”h)”}”(hjh]”hÊ)”}”(hjh]”hŒ#Documentation/process/5.Posting.rst”…””}”(hj"h²hh³Nh´Nubah}”(h]”h ]”(hÕŒstd”Œstd-ref”eh"]”h$]”h&]”uh1hÉhjubah}”(h]”h ]”h"]”h$]”h&]”Œrefdoc”h⌠refdomain”j,Œreftype”Œref”Œ refexplicit”ˆŒrefwarn”ˆhèŒdevelopment_posting”uh1hh³jh´Khjubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´Khjubah}”(h]”h ]”h"]”h$]”h&]”uh1jhjubeh}”(h]”h ]”h"]”h$]”h&]”uh1jh³jh´Khhýh²hubj)”}”(hhh]”(j)”}”(hŒ Translator”h]”hŒ Translator”…””}”(hjSh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jhjPh³jh´Kubj)”}”(hŒ)Federico Vaga ”h]”h¼)”}”(hŒ(Federico Vaga ”h]”(hŒFederico Vaga <”…””}”(hjeh²hh³Nh´NubhŒ reference”“”)”}”(hŒfederico.vaga@vaga.pv.it”h]”hŒfederico.vaga@vaga.pv.it”…””}”(hjoh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”Œrefuri”Œmailto:federico.vaga@vaga.pv.it”uh1jmhjeubhŒ>”…””}”(hjeh²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´Khjaubah}”(h]”h ]”h"]”h$]”h&]”uh1jhjPubeh}”(h]”h ]”h"]”h$]”h&]”uh1jh³jh´Khhýh²hubeh}”(h]”h ]”h"]”h$]”h&]”uh1hûhhh²hh³jh´KubhŒtarget”“”)”}”(hŒ.. _it_development_posting:”h]”h}”(h]”h ]”h"]”h$]”h&]”Œrefid”Œit-development-posting”uh1j›h´Khhh²hh³jubhŒsection”“”)”}”(hhh]”(hŒtitle”“”)”}”(hŒPubblicare modifiche”h]”hŒPubblicare modifiche”…””}”(hj°h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j®hj«h²hh³jh´K ubh¼)”}”(hX×Prima o poi arriva il momento in cui il vostro lavoro è pronto per essere presentato alla comunità per una revisione ed eventualmente per la sua inclusione nel ramo principale del kernel. Com'era prevedibile, la comunità di sviluppo del kernel ha elaborato un insieme di convenzioni e di procedure per la pubblicazione delle patch; seguirle renderà la vita più facile a tutti quanti. Questo documento cercherà di coprire questi argomenti con un ragionevole livello di dettaglio; più informazioni possono essere trovare nella cartella 'Documentation', nei file :ref:`translations/it_IT/process/submitting-patches.rst ` e :ref:`translations/it_IT/process/submit-checklist.rst `.”h]”(hX?Prima o poi arriva il momento in cui il vostro lavoro è pronto per essere presentato alla comunità per una revisione ed eventualmente per la sua inclusione nel ramo principale del kernel. Com’era prevedibile, la comunità di sviluppo del kernel ha elaborato un insieme di convenzioni e di procedure per la pubblicazione delle patch; seguirle renderà la vita più facile a tutti quanti. Questo documento cercherà di coprire questi argomenti con un ragionevole livello di dettaglio; più informazioni possono essere trovare nella cartella ‘Documentation’, nei file ”…””}”(hj¾h²hh³Nh´Nubh)”}”(hŒO:ref:`translations/it_IT/process/submitting-patches.rst `”h]”hÊ)”}”(hjÈh]”hŒ1translations/it_IT/process/submitting-patches.rst”…””}”(hjÊh²hh³Nh´Nubah}”(h]”h ]”(hÕŒstd”Œstd-ref”eh"]”h$]”h&]”uh1hÉhjÆubah}”(h]”h ]”h"]”h$]”h&]”Œrefdoc”h⌠refdomain”jÔŒreftype”Œref”Œ refexplicit”ˆŒrefwarn”ˆhèŒit_submittingpatches”uh1hh³jh´K hj¾ubhŒ e ”…””}”(hj¾h²hh³Nh´Nubh)”}”(hŒK:ref:`translations/it_IT/process/submit-checklist.rst `”h]”hÊ)”}”(hjìh]”hŒ/translations/it_IT/process/submit-checklist.rst”…””}”(hjîh²hh³Nh´Nubah}”(h]”h ]”(hÕŒstd”Œstd-ref”eh"]”h$]”h&]”uh1hÉhjêubah}”(h]”h ]”h"]”h$]”h&]”Œrefdoc”h⌠refdomain”jøŒreftype”Œref”Œ refexplicit”ˆŒrefwarn”ˆhèŒit_submitchecklist”uh1hh³jh´K hj¾ubhŒ.”…””}”(hj¾h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´K hj«h²hubjª)”}”(hhh]”(j¯)”}”(hŒQuando pubblicarle”h]”hŒQuando pubblicarle”…””}”(hjh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j®hjh²hh³jh´Kubh¼)”}”(hXñC'è sempre una certa resistenza nel pubblicare patch finché non sono veramente "pronte". Per semplici patch questo non è un problema. Ma quando il lavoro è di una certa complessità, c'è molto da guadagnare dai riscontri che la comunità può darvi prima che completiate il lavoro. Dovreste considerare l'idea di pubblicare un lavoro incompleto, o anche preparare un ramo git disponibile agli sviluppatori interessati, cosicché possano stare al passo col vostro lavoro in qualunque momento.”h]”hXûC’è sempre una certa resistenza nel pubblicare patch finché non sono veramente “pronteâ€. Per semplici patch questo non è un problema. Ma quando il lavoro è di una certa complessità, c’è molto da guadagnare dai riscontri che la comunità può darvi prima che completiate il lavoro. Dovreste considerare l’idea di pubblicare un lavoro incompleto, o anche preparare un ramo git disponibile agli sviluppatori interessati, cosicché possano stare al passo col vostro lavoro in qualunque momento.”…””}”(hj%h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´Khjh²hubh¼)”}”(hX“Quando pubblicate del codice che non è considerato pronto per l'inclusione, è bene che lo diciate al momento della pubblicazione. Inoltre, aggiungete informazioni sulle cose ancora da sviluppare e sui problemi conosciuti. Poche persone guarderanno delle patch che si sa essere fatte a metà, ma quelli che lo faranno penseranno di potervi aiutare a condurre il vostro sviluppo nella giusta direzione.”h]”hX•Quando pubblicate del codice che non è considerato pronto per l’inclusione, è bene che lo diciate al momento della pubblicazione. Inoltre, aggiungete informazioni sulle cose ancora da sviluppare e sui problemi conosciuti. Poche persone guarderanno delle patch che si sa essere fatte a metà, ma quelli che lo faranno penseranno di potervi aiutare a condurre il vostro sviluppo nella giusta direzione.”…””}”(hj3h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´K"hjh²hubeh}”(h]”Œquando-pubblicarle”ah ]”h"]”Œquando pubblicarle”ah$]”h&]”uh1j©hj«h²hh³jh´Kubjª)”}”(hhh]”(j¯)”}”(hŒPrima di creare patch”h]”hŒPrima di creare patch”…””}”(hjLh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j®hjIh²hh³jh´K+ubh¼)”}”(hŒŽCi sono un certo numero di cose che dovreste fare prima di considerare l'invio delle patch alla comunità di sviluppo. Queste cose includono:”h]”hŒCi sono un certo numero di cose che dovreste fare prima di considerare l’invio delle patch alla comunità di sviluppo. Queste cose includono:”…””}”(hjZh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´K-hjIh²hubhŒ block_quote”“”)”}”(hXZ- Verificare il codice fino al massimo che vi è consentito. Usate gli strumenti di debug del kernel, assicuratevi che il kernel compili con tutte le più ragionevoli combinazioni d'opzioni, usate cross-compilatori per compilare il codice per differenti architetture, eccetera. - Assicuratevi che il vostro codice sia conforme alla linee guida del kernel sullo stile del codice. - La vostra patch ha delle conseguenze in termini di prestazioni? Se è così, dovreste eseguire dei *benchmark* che mostrino il loro impatto (anche positivo); un riassunto dei risultati dovrebbe essere incluso nella patch. - Siate certi d'avere i diritti per pubblicare il codice. Se questo lavoro è stato fatto per un datore di lavoro, egli avrà dei diritti su questo lavoro e dovrà quindi essere d'accordo alla sua pubblicazione con una licenza GPL ”h]”hŒ bullet_list”“”)”}”(hhh]”(hŒ list_item”“”)”}”(hXVerificare il codice fino al massimo che vi è consentito. Usate gli strumenti di debug del kernel, assicuratevi che il kernel compili con tutte le più ragionevoli combinazioni d'opzioni, usate cross-compilatori per compilare il codice per differenti architetture, eccetera. ”h]”h¼)”}”(hXVerificare il codice fino al massimo che vi è consentito. Usate gli strumenti di debug del kernel, assicuratevi che il kernel compili con tutte le più ragionevoli combinazioni d'opzioni, usate cross-compilatori per compilare il codice per differenti architetture, eccetera.”h]”hXVerificare il codice fino al massimo che vi è consentito. Usate gli strumenti di debug del kernel, assicuratevi che il kernel compili con tutte le più ragionevoli combinazioni d’opzioni, usate cross-compilatori per compilare il codice per differenti architetture, eccetera.”…””}”(hjyh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´K0hjuubah}”(h]”h ]”h"]”h$]”h&]”uh1jshjpubjt)”}”(hŒcAssicuratevi che il vostro codice sia conforme alla linee guida del kernel sullo stile del codice. ”h]”h¼)”}”(hŒbAssicuratevi che il vostro codice sia conforme alla linee guida del kernel sullo stile del codice.”h]”hŒbAssicuratevi che il vostro codice sia conforme alla linee guida del kernel sullo stile del codice.”…””}”(hj‘h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´K5hjubah}”(h]”h ]”h"]”h$]”h&]”uh1jshjpubjt)”}”(hŒÞLa vostra patch ha delle conseguenze in termini di prestazioni? Se è così, dovreste eseguire dei *benchmark* che mostrino il loro impatto (anche positivo); un riassunto dei risultati dovrebbe essere incluso nella patch. ”h]”h¼)”}”(hŒÝLa vostra patch ha delle conseguenze in termini di prestazioni? Se è così, dovreste eseguire dei *benchmark* che mostrino il loro impatto (anche positivo); un riassunto dei risultati dovrebbe essere incluso nella patch.”h]”(hŒcLa vostra patch ha delle conseguenze in termini di prestazioni? Se è così, dovreste eseguire dei ”…””}”(hj©h²hh³Nh´NubhŒemphasis”“”)”}”(hŒ *benchmark*”h]”hŒ benchmark”…””}”(hj³h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j±hj©ubhŒo che mostrino il loro impatto (anche positivo); un riassunto dei risultati dovrebbe essere incluso nella patch.”…””}”(hj©h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´K8hj¥ubah}”(h]”h ]”h"]”h$]”h&]”uh1jshjpubjt)”}”(hŒæSiate certi d'avere i diritti per pubblicare il codice. Se questo lavoro è stato fatto per un datore di lavoro, egli avrà dei diritti su questo lavoro e dovrà quindi essere d'accordo alla sua pubblicazione con una licenza GPL ”h]”h¼)”}”(hŒåSiate certi d'avere i diritti per pubblicare il codice. Se questo lavoro è stato fatto per un datore di lavoro, egli avrà dei diritti su questo lavoro e dovrà quindi essere d'accordo alla sua pubblicazione con una licenza GPL”h]”hŒéSiate certi d’avere i diritti per pubblicare il codice. Se questo lavoro è stato fatto per un datore di lavoro, egli avrà dei diritti su questo lavoro e dovrà quindi essere d’accordo alla sua pubblicazione con una licenza GPL”…””}”(hjÕh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´K=hjÑubah}”(h]”h ]”h"]”h$]”h&]”uh1jshjpubeh}”(h]”h ]”h"]”h$]”h&]”Œbullet”Œ-”uh1jnh³jh´K0hjjubah}”(h]”h ]”h"]”h$]”h&]”uh1jhh³jh´K0hjIh²hubh¼)”}”(hŒgCome regola generale, pensarci un po' di più prima di inviare il codice ripaga quasi sempre lo sforzo.”h]”hŒiCome regola generale, pensarci un po’ di più prima di inviare il codice ripaga quasi sempre lo sforzo.”…””}”(hj÷h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´KBhjIh²hubeh}”(h]”Œprima-di-creare-patch”ah ]”h"]”Œprima di creare patch”ah$]”h&]”uh1j©hj«h²hh³jh´K+ubjª)”}”(hhh]”(j¯)”}”(hŒPreparazione di una patch”h]”hŒPreparazione di una patch”…””}”(hjh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j®hj h²hh³jh´KGubh¼)”}”(hŒ×La preparazione delle patch per la pubblicazione può richiedere una quantità di lavoro significativa, ma, ripetiamolo ancora, generalmente sconsigliamo di risparmiare tempo in questa fase, anche sul breve periodo.”h]”hŒ×La preparazione delle patch per la pubblicazione può richiedere una quantità di lavoro significativa, ma, ripetiamolo ancora, generalmente sconsigliamo di risparmiare tempo in questa fase, anche sul breve periodo.”…””}”(hjh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´KIhj h²hubh¼)”}”(hXLe patch devono essere preparate per una specifica versione del kernel. Come regola generale, una patch dovrebbe basarsi sul ramo principale attuale così come lo si trova nei sorgenti git di Linus. Quando vi basate sul ramo principale, cominciate da un punto di rilascio ben noto - uno stabile o un -rc - piuttosto che creare il vostro ramo da quello principale in un punto a caso.”h]”hXLe patch devono essere preparate per una specifica versione del kernel. Come regola generale, una patch dovrebbe basarsi sul ramo principale attuale così come lo si trova nei sorgenti git di Linus. Quando vi basate sul ramo principale, cominciate da un punto di rilascio ben noto - uno stabile o un -rc - piuttosto che creare il vostro ramo da quello principale in un punto a caso.”…””}”(hj,h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´KMhj h²hubh¼)”}”(hX¾Per facilitare una revisione e una verifica più estesa, potrebbe diventare necessaria la produzione di versioni per -mm, linux-next o i sorgenti di un sottosistema. Basare questa patch sui suddetti sorgenti potrebbe richiedere un lavoro significativo nella risoluzione dei conflitti e nella correzione dei cambiamenti di API; questo potrebbe variare a seconda dell'area d'interesse della vostra patch e da quello che succede altrove nel kernel.”h]”hXÂPer facilitare una revisione e una verifica più estesa, potrebbe diventare necessaria la produzione di versioni per -mm, linux-next o i sorgenti di un sottosistema. Basare questa patch sui suddetti sorgenti potrebbe richiedere un lavoro significativo nella risoluzione dei conflitti e nella correzione dei cambiamenti di API; questo potrebbe variare a seconda dell’area d’interesse della vostra patch e da quello che succede altrove nel kernel.”…””}”(hj:h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´KThj h²hubh¼)”}”(hXSolo le modifiche più semplici dovrebbero essere preparate come una singola patch; tutto il resto dovrebbe essere preparato come una serie logica di modifiche. Spezzettare le patch è un po' un'arte; alcuni sviluppatori passano molto tempo nel capire come farlo in modo che piaccia alla comunità. Ci sono alcune regole spannometriche, che comunque possono aiutare considerevolmente:”h]”hX…Solo le modifiche più semplici dovrebbero essere preparate come una singola patch; tutto il resto dovrebbe essere preparato come una serie logica di modifiche. Spezzettare le patch è un po’ un’arte; alcuni sviluppatori passano molto tempo nel capire come farlo in modo che piaccia alla comunità. Ci sono alcune regole spannometriche, che comunque possono aiutare considerevolmente:”…””}”(hjHh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´K[hj h²hubji)”}”(hX - La serie di patch che pubblicherete, quasi sicuramente, non sarà come quella che trovate nel vostro sistema di controllo di versione. Invece, le vostre modifiche dovranno essere considerate nella loro forma finale, e quindi separate in parti che abbiano un senso. Gli sviluppatori sono interessati in modifiche che siano discrete e indipendenti, non alla strada che avete percorso per ottenerle. - Ogni modifica logicamente indipendente dovrebbe essere preparata come una patch separata. Queste modifiche possono essere piccole ("aggiunto un campo in questa struttura") o grandi (l'aggiunta di un driver nuovo, per esempio), ma dovrebbero essere concettualmente piccole da permettere una descrizione in una sola riga. Ogni patch dovrebbe fare modifiche specifiche che si possano revisionare indipendentemente e di cui si possa verificare la veridicità. - Giusto per riaffermare quando detto sopra: non mischiate diversi tipi di modifiche nella stessa patch. Se una modifica corregge un baco critico per la sicurezza, riorganizza alcune strutture, e riformatta il codice, ci sono buone probabilità che venga ignorata e che la correzione importante venga persa. - Ogni modifica dovrebbe portare ad un kernel che compila e funziona correttamente; se la vostra serie di patch si interrompe a metà il risultato dovrebbe essere comunque un kernel funzionante. L'applicazione parziale di una serie di patch è uno scenario comune nel quale il comando "git bisect" viene usato per trovare delle regressioni; se il risultato è un kernel guasto, renderete la vita degli sviluppatori più difficile così come quella di chi s'impegna nel nobile lavoro di scovare i problemi. - Però, non strafate. Una volta uno sviluppatore pubblicò una serie di 500 patch che modificavano un unico file - un atto che non lo rese la persona più popolare sulla lista di discussione del kernel. Una singola patch può essere ragionevolmente grande fintanto che contenga un singolo cambiamento *logico*. - Potrebbe essere allettante l'idea di aggiungere una nuova infrastruttura come una serie di patch, ma di lasciare questa infrastruttura inutilizzata finché l'ultima patch della serie non abilita tutto quanto. Quando è possibile, questo dovrebbe essere evitato; se questa serie aggiunge delle regressioni, "bisect" indicherà quest'ultima patch come causa del problema anche se il baco si trova altrove. Possibilmente, quando una patch aggiunge del nuovo codice dovrebbe renderlo attivo immediatamente. ”h]”jo)”}”(hhh]”(jt)”}”(hXŽLa serie di patch che pubblicherete, quasi sicuramente, non sarà come quella che trovate nel vostro sistema di controllo di versione. Invece, le vostre modifiche dovranno essere considerate nella loro forma finale, e quindi separate in parti che abbiano un senso. Gli sviluppatori sono interessati in modifiche che siano discrete e indipendenti, non alla strada che avete percorso per ottenerle. ”h]”h¼)”}”(hXLa serie di patch che pubblicherete, quasi sicuramente, non sarà come quella che trovate nel vostro sistema di controllo di versione. Invece, le vostre modifiche dovranno essere considerate nella loro forma finale, e quindi separate in parti che abbiano un senso. Gli sviluppatori sono interessati in modifiche che siano discrete e indipendenti, non alla strada che avete percorso per ottenerle.”h]”hXLa serie di patch che pubblicherete, quasi sicuramente, non sarà come quella che trovate nel vostro sistema di controllo di versione. Invece, le vostre modifiche dovranno essere considerate nella loro forma finale, e quindi separate in parti che abbiano un senso. Gli sviluppatori sono interessati in modifiche che siano discrete e indipendenti, non alla strada che avete percorso per ottenerle.”…””}”(hjah²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´Kbhj]ubah}”(h]”h ]”h"]”h$]”h&]”uh1jshjZubjt)”}”(hXÊOgni modifica logicamente indipendente dovrebbe essere preparata come una patch separata. Queste modifiche possono essere piccole ("aggiunto un campo in questa struttura") o grandi (l'aggiunta di un driver nuovo, per esempio), ma dovrebbero essere concettualmente piccole da permettere una descrizione in una sola riga. Ogni patch dovrebbe fare modifiche specifiche che si possano revisionare indipendentemente e di cui si possa verificare la veridicità. ”h]”h¼)”}”(hXÉOgni modifica logicamente indipendente dovrebbe essere preparata come una patch separata. Queste modifiche possono essere piccole ("aggiunto un campo in questa struttura") o grandi (l'aggiunta di un driver nuovo, per esempio), ma dovrebbero essere concettualmente piccole da permettere una descrizione in una sola riga. Ogni patch dovrebbe fare modifiche specifiche che si possano revisionare indipendentemente e di cui si possa verificare la veridicità.”h]”hXÏOgni modifica logicamente indipendente dovrebbe essere preparata come una patch separata. Queste modifiche possono essere piccole (“aggiunto un campo in questa strutturaâ€) o grandi (l’aggiunta di un driver nuovo, per esempio), ma dovrebbero essere concettualmente piccole da permettere una descrizione in una sola riga. Ogni patch dovrebbe fare modifiche specifiche che si possano revisionare indipendentemente e di cui si possa verificare la veridicità.”…””}”(hjyh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´Kihjuubah}”(h]”h ]”h"]”h$]”h&]”uh1jshjZubjt)”}”(hX3Giusto per riaffermare quando detto sopra: non mischiate diversi tipi di modifiche nella stessa patch. Se una modifica corregge un baco critico per la sicurezza, riorganizza alcune strutture, e riformatta il codice, ci sono buone probabilità che venga ignorata e che la correzione importante venga persa. ”h]”h¼)”}”(hX2Giusto per riaffermare quando detto sopra: non mischiate diversi tipi di modifiche nella stessa patch. Se una modifica corregge un baco critico per la sicurezza, riorganizza alcune strutture, e riformatta il codice, ci sono buone probabilità che venga ignorata e che la correzione importante venga persa.”h]”hX2Giusto per riaffermare quando detto sopra: non mischiate diversi tipi di modifiche nella stessa patch. Se una modifica corregge un baco critico per la sicurezza, riorganizza alcune strutture, e riformatta il codice, ci sono buone probabilità che venga ignorata e che la correzione importante venga persa.”…””}”(hj‘h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´Kqhjubah}”(h]”h ]”h"]”h$]”h&]”uh1jshjZubjt)”}”(hXùOgni modifica dovrebbe portare ad un kernel che compila e funziona correttamente; se la vostra serie di patch si interrompe a metà il risultato dovrebbe essere comunque un kernel funzionante. L'applicazione parziale di una serie di patch è uno scenario comune nel quale il comando "git bisect" viene usato per trovare delle regressioni; se il risultato è un kernel guasto, renderete la vita degli sviluppatori più difficile così come quella di chi s'impegna nel nobile lavoro di scovare i problemi. ”h]”h¼)”}”(hXøOgni modifica dovrebbe portare ad un kernel che compila e funziona correttamente; se la vostra serie di patch si interrompe a metà il risultato dovrebbe essere comunque un kernel funzionante. L'applicazione parziale di una serie di patch è uno scenario comune nel quale il comando "git bisect" viene usato per trovare delle regressioni; se il risultato è un kernel guasto, renderete la vita degli sviluppatori più difficile così come quella di chi s'impegna nel nobile lavoro di scovare i problemi.”h]”hXOgni modifica dovrebbe portare ad un kernel che compila e funziona correttamente; se la vostra serie di patch si interrompe a metà il risultato dovrebbe essere comunque un kernel funzionante. L’applicazione parziale di una serie di patch è uno scenario comune nel quale il comando “git bisect†viene usato per trovare delle regressioni; se il risultato è un kernel guasto, renderete la vita degli sviluppatori più difficile così come quella di chi s’impegna nel nobile lavoro di scovare i problemi.”…””}”(hj©h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´Kwhj¥ubah}”(h]”h ]”h"]”h$]”h&]”uh1jshjZubjt)”}”(hX8Però, non strafate. Una volta uno sviluppatore pubblicò una serie di 500 patch che modificavano un unico file - un atto che non lo rese la persona più popolare sulla lista di discussione del kernel. Una singola patch può essere ragionevolmente grande fintanto che contenga un singolo cambiamento *logico*. ”h]”h¼)”}”(hX7Però, non strafate. Una volta uno sviluppatore pubblicò una serie di 500 patch che modificavano un unico file - un atto che non lo rese la persona più popolare sulla lista di discussione del kernel. Una singola patch può essere ragionevolmente grande fintanto che contenga un singolo cambiamento *logico*.”h]”(hX.Però, non strafate. Una volta uno sviluppatore pubblicò una serie di 500 patch che modificavano un unico file - un atto che non lo rese la persona più popolare sulla lista di discussione del kernel. Una singola patch può essere ragionevolmente grande fintanto che contenga un singolo cambiamento ”…””}”(hjÁh²hh³Nh´Nubj²)”}”(hŒ*logico*”h]”hŒlogico”…””}”(hjÉh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j±hjÁubhŒ.”…””}”(hjÁh²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´K€hj½ubah}”(h]”h ]”h"]”h$]”h&]”uh1jshjZubjt)”}”(hXùPotrebbe essere allettante l'idea di aggiungere una nuova infrastruttura come una serie di patch, ma di lasciare questa infrastruttura inutilizzata finché l'ultima patch della serie non abilita tutto quanto. Quando è possibile, questo dovrebbe essere evitato; se questa serie aggiunge delle regressioni, "bisect" indicherà quest'ultima patch come causa del problema anche se il baco si trova altrove. Possibilmente, quando una patch aggiunge del nuovo codice dovrebbe renderlo attivo immediatamente. ”h]”h¼)”}”(hXøPotrebbe essere allettante l'idea di aggiungere una nuova infrastruttura come una serie di patch, ma di lasciare questa infrastruttura inutilizzata finché l'ultima patch della serie non abilita tutto quanto. Quando è possibile, questo dovrebbe essere evitato; se questa serie aggiunge delle regressioni, "bisect" indicherà quest'ultima patch come causa del problema anche se il baco si trova altrove. Possibilmente, quando una patch aggiunge del nuovo codice dovrebbe renderlo attivo immediatamente.”h]”hXPotrebbe essere allettante l’idea di aggiungere una nuova infrastruttura come una serie di patch, ma di lasciare questa infrastruttura inutilizzata finché l’ultima patch della serie non abilita tutto quanto. Quando è possibile, questo dovrebbe essere evitato; se questa serie aggiunge delle regressioni, “bisect†indicherà quest’ultima patch come causa del problema anche se il baco si trova altrove. Possibilmente, quando una patch aggiunge del nuovo codice dovrebbe renderlo attivo immediatamente.”…””}”(hjëh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´K†hjçubah}”(h]”h ]”h"]”h$]”h&]”uh1jshjZubeh}”(h]”h ]”h"]”h$]”h&]”jïjðuh1jnh³jh´KbhjVubah}”(h]”h ]”h"]”h$]”h&]”uh1jhh³jh´Kbhj h²hubh¼)”}”(hŒ×Lavorare per creare la serie di patch perfetta potrebbe essere frustrante perché richiede un certo tempo e soprattutto dopo che il "vero lavoro" è già stato fatto. Quando ben fatto, comunque, è tempo ben speso.”h]”hŒÛLavorare per creare la serie di patch perfetta potrebbe essere frustrante perché richiede un certo tempo e soprattutto dopo che il “vero lavoro†è già stato fatto. Quando ben fatto, comunque, è tempo ben speso.”…””}”(hj h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´KŽhj h²hubeh}”(h]”Œpreparazione-di-una-patch”ah ]”h"]”Œpreparazione di una patch”ah$]”h&]”uh1j©hj«h²hh³jh´KGubjª)”}”(hhh]”(j¯)”}”(hŒ'Formattazione delle patch e i changelog”h]”hŒ'Formattazione delle patch e i changelog”…””}”(hj$h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j®hj!h²hh³jh´K”ubh¼)”}”(hX+Quindi adesso avete una serie perfetta di patch pronte per la pubblicazione, ma il lavoro non è davvero finito. Ogni patch deve essere preparata con un messaggio che spieghi al resto del mondo, in modo chiaro e veloce, il suo scopo. Per ottenerlo, ogni patch sarà composta dai seguenti elementi:”h]”hX+Quindi adesso avete una serie perfetta di patch pronte per la pubblicazione, ma il lavoro non è davvero finito. Ogni patch deve essere preparata con un messaggio che spieghi al resto del mondo, in modo chiaro e veloce, il suo scopo. Per ottenerlo, ogni patch sarà composta dai seguenti elementi:”…””}”(hj2h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´K–hj!h²hubji)”}”(hX¾- Un campo opzionale "From" col nome dell'autore della patch. Questa riga è necessaria solo se state passando la patch di qualcun altro via email, ma nel dubbio non fa di certo male aggiungerlo. - Una descrizione di una riga che spieghi cosa fa la patch. Questo messaggio dovrebbe essere sufficiente per far comprendere al lettore lo scopo della patch senza altre informazioni. Questo messaggio, solitamente, presenta in testa il nome del sottosistema a cui si riferisce, seguito dallo scopo della patch. Per esempio: :: gpio: fix build on CONFIG_GPIO_SYSFS=n - Una riga bianca seguita da una descrizione dettagliata della patch. Questa descrizione può essere lunga tanto quanto serve; dovrebbe spiegare cosa fa e perché dovrebbe essere aggiunta al kernel. - Una o più righe etichette, con, minimo, una riga *Signed-off-by:* col nome dall'autore della patch. Queste etichette verranno descritte meglio più avanti. ”h]”jo)”}”(hhh]”(jt)”}”(hŒÃUn campo opzionale "From" col nome dell'autore della patch. Questa riga è necessaria solo se state passando la patch di qualcun altro via email, ma nel dubbio non fa di certo male aggiungerlo. ”h]”h¼)”}”(hŒÂUn campo opzionale "From" col nome dell'autore della patch. Questa riga è necessaria solo se state passando la patch di qualcun altro via email, ma nel dubbio non fa di certo male aggiungerlo.”h]”hŒÈUn campo opzionale “From†col nome dell’autore della patch. Questa riga è necessaria solo se state passando la patch di qualcun altro via email, ma nel dubbio non fa di certo male aggiungerlo.”…””}”(hjKh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´K›hjGubah}”(h]”h ]”h"]”h$]”h&]”uh1jshjDubjt)”}”(hXuUna descrizione di una riga che spieghi cosa fa la patch. Questo messaggio dovrebbe essere sufficiente per far comprendere al lettore lo scopo della patch senza altre informazioni. Questo messaggio, solitamente, presenta in testa il nome del sottosistema a cui si riferisce, seguito dallo scopo della patch. Per esempio: :: gpio: fix build on CONFIG_GPIO_SYSFS=n ”h]”(h¼)”}”(hXCUna descrizione di una riga che spieghi cosa fa la patch. Questo messaggio dovrebbe essere sufficiente per far comprendere al lettore lo scopo della patch senza altre informazioni. Questo messaggio, solitamente, presenta in testa il nome del sottosistema a cui si riferisce, seguito dallo scopo della patch. Per esempio:”h]”hXCUna descrizione di una riga che spieghi cosa fa la patch. Questo messaggio dovrebbe essere sufficiente per far comprendere al lettore lo scopo della patch senza altre informazioni. Questo messaggio, solitamente, presenta in testa il nome del sottosistema a cui si riferisce, seguito dallo scopo della patch. Per esempio:”…””}”(hjch²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´KŸhj_ubhŒ literal_block”“”)”}”(hŒ&gpio: fix build on CONFIG_GPIO_SYSFS=n”h]”hŒ&gpio: fix build on CONFIG_GPIO_SYSFS=n”…””}”hjssbah}”(h]”h ]”h"]”h$]”h&]”Œ xml:space”Œpreserve”uh1jqh³jh´K§hj_ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jshjDubjt)”}”(hŒÅUna riga bianca seguita da una descrizione dettagliata della patch. Questa descrizione può essere lunga tanto quanto serve; dovrebbe spiegare cosa fa e perché dovrebbe essere aggiunta al kernel. ”h]”h¼)”}”(hŒÄUna riga bianca seguita da una descrizione dettagliata della patch. Questa descrizione può essere lunga tanto quanto serve; dovrebbe spiegare cosa fa e perché dovrebbe essere aggiunta al kernel.”h]”hŒÄUna riga bianca seguita da una descrizione dettagliata della patch. Questa descrizione può essere lunga tanto quanto serve; dovrebbe spiegare cosa fa e perché dovrebbe essere aggiunta al kernel.”…””}”(hjh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´K©hj‰ubah}”(h]”h ]”h"]”h$]”h&]”uh1jshjDubjt)”}”(hŒžUna o più righe etichette, con, minimo, una riga *Signed-off-by:* col nome dall'autore della patch. Queste etichette verranno descritte meglio più avanti. ”h]”h¼)”}”(hŒUna o più righe etichette, con, minimo, una riga *Signed-off-by:* col nome dall'autore della patch. Queste etichette verranno descritte meglio più avanti.”h]”(hŒ2Una o più righe etichette, con, minimo, una riga ”…””}”(hj¥h²hh³Nh´Nubj²)”}”(hŒ*Signed-off-by:*”h]”hŒSigned-off-by:”…””}”(hj­h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j±hj¥ubhŒ] col nome dall’autore della patch. Queste etichette verranno descritte meglio più avanti.”…””}”(hj¥h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´K­hj¡ubah}”(h]”h ]”h"]”h$]”h&]”uh1jshjDubeh}”(h]”h ]”h"]”h$]”h&]”jïjðuh1jnh³jh´K›hj@ubah}”(h]”h ]”h"]”h$]”h&]”uh1jhh³jh´K›hj!h²hubh¼)”}”(hXIGli elementi qui sopra, assieme, formano il changelog di una patch. Scrivere un buon changelog è cruciale ma è spesso un'arte trascurata; vale la pena spendere qualche parola in più al riguardo. Quando scrivete un changelog dovreste tenere ben presente che molte persone leggeranno le vostre parole. Queste includono i manutentori di un sotto-sistema, e i revisori che devono decidere se la patch debba essere inclusa o no, le distribuzioni e altri manutentori che cercano di valutare se la patch debba essere applicata su kernel più vecchi, i cacciatori di bachi che si chiederanno se la patch è la causa di un problema che stanno cercando, gli utenti che vogliono sapere com'è cambiato il kernel, e molti altri. Un buon changelog fornisce le informazioni necessarie a tutte queste persone nel modo più diretto e conciso possibile.”h]”hXMGli elementi qui sopra, assieme, formano il changelog di una patch. Scrivere un buon changelog è cruciale ma è spesso un’arte trascurata; vale la pena spendere qualche parola in più al riguardo. Quando scrivete un changelog dovreste tenere ben presente che molte persone leggeranno le vostre parole. Queste includono i manutentori di un sotto-sistema, e i revisori che devono decidere se la patch debba essere inclusa o no, le distribuzioni e altri manutentori che cercano di valutare se la patch debba essere applicata su kernel più vecchi, i cacciatori di bachi che si chiederanno se la patch è la causa di un problema che stanno cercando, gli utenti che vogliono sapere com’è cambiato il kernel, e molti altri. Un buon changelog fornisce le informazioni necessarie a tutte queste persone nel modo più diretto e conciso possibile.”…””}”(hj×h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´K±hj!h²hubh¼)”}”(hXÁA questo scopo, la riga riassuntiva dovrebbe descrivere gli effetti della modifica e la motivazione della patch nel modo migliore possibile nonostante il limite di una sola riga. La descrizione dettagliata può spiegare meglio i temi e fornire maggiori informazioni. Se una patch corregge un baco, citate, se possibile, il commit che lo introdusse (e per favore, quando citate un commit aggiungete sia il suo identificativo che il titolo), Se il problema è associabile ad un file di log o all' output del compilatore, includeteli al fine d'aiutare gli altri a trovare soluzioni per lo stesso problema. Se la modifica ha lo scopo di essere di supporto a sviluppi successivi, ditelo. Se le API interne vengono cambiate, dettagliate queste modifiche e come gli altri dovrebbero agire per applicarle. In generale, più riuscirete ad entrare nei panni di tutti quelli che leggeranno il vostro changelog, meglio sarà il changelog (e il kernel nel suo insieme).”h]”hXÅA questo scopo, la riga riassuntiva dovrebbe descrivere gli effetti della modifica e la motivazione della patch nel modo migliore possibile nonostante il limite di una sola riga. La descrizione dettagliata può spiegare meglio i temi e fornire maggiori informazioni. Se una patch corregge un baco, citate, se possibile, il commit che lo introdusse (e per favore, quando citate un commit aggiungete sia il suo identificativo che il titolo), Se il problema è associabile ad un file di log o all’ output del compilatore, includeteli al fine d’aiutare gli altri a trovare soluzioni per lo stesso problema. Se la modifica ha lo scopo di essere di supporto a sviluppi successivi, ditelo. Se le API interne vengono cambiate, dettagliate queste modifiche e come gli altri dovrebbero agire per applicarle. In generale, più riuscirete ad entrare nei panni di tutti quelli che leggeranno il vostro changelog, meglio sarà il changelog (e il kernel nel suo insieme).”…””}”(hjåh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´K¾hj!h²hubh¼)”}”(hŒNon serve dirlo, un changelog dovrebbe essere il testo usato nel messaggio di commit in un sistema di controllo di versione. Sarà seguito da:”h]”hŒNon serve dirlo, un changelog dovrebbe essere il testo usato nel messaggio di commit in un sistema di controllo di versione. Sarà seguito da:”…””}”(hjóh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´KÌhj!h²hubji)”}”(hŒÙ- La patch stessa, nel formato unificato per patch ("-u"). Usare l'opzione "-p" assocerà alla modifica il nome della funzione alla quale si riferisce, rendendo il risultato più facile da leggere per gli altri. ”h]”jo)”}”(hhh]”jt)”}”(hŒÓLa patch stessa, nel formato unificato per patch ("-u"). Usare l'opzione "-p" assocerà alla modifica il nome della funzione alla quale si riferisce, rendendo il risultato più facile da leggere per gli altri. ”h]”h¼)”}”(hŒÒLa patch stessa, nel formato unificato per patch ("-u"). Usare l'opzione "-p" assocerà alla modifica il nome della funzione alla quale si riferisce, rendendo il risultato più facile da leggere per gli altri.”h]”hŒÜLa patch stessa, nel formato unificato per patch (“-uâ€). Usare l’opzione “-p†assocerà alla modifica il nome della funzione alla quale si riferisce, rendendo il risultato più facile da leggere per gli altri.”…””}”(hj h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´KÏhjubah}”(h]”h ]”h"]”h$]”h&]”uh1jshjubah}”(h]”h ]”h"]”h$]”h&]”jïjðuh1jnh³jh´KÏhjubah}”(h]”h ]”h"]”h$]”h&]”uh1jhh³jh´KÏhj!h²hubh¼)”}”(hŒóLe etichette sopracitate danno un'idea di come una patch prende vita e sono descritte nel dettaglio nel documento :ref:`Documentation/translations/it_IT/process/submitting-patches.rst `. Qui di seguito un breve riassunto.”h]”(hŒtLe etichette sopracitate danno un’idea di come una patch prende vita e sono descritte nel dettaglio nel documento ”…””}”(hj,h²hh³Nh´Nubh)”}”(hŒ]:ref:`Documentation/translations/it_IT/process/submitting-patches.rst `”h]”hÊ)”}”(hj6h]”hŒ?Documentation/translations/it_IT/process/submitting-patches.rst”…””}”(hj8h²hh³Nh´Nubah}”(h]”h ]”(hÕŒstd”Œstd-ref”eh"]”h$]”h&]”uh1hÉhj4ubah}”(h]”h ]”h"]”h$]”h&]”Œrefdoc”h⌠refdomain”jBŒreftype”Œref”Œ refexplicit”ˆŒrefwarn”ˆhèŒit_submittingpatches”uh1hh³jh´KÓhj,ubhŒ$. Qui di seguito un breve riassunto.”…””}”(hj,h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´KÓhj!h²hubh¼)”}”(hŒaUn'etichetta ci può dire quale commit ha introdotto il problema che viene corretto nella patch::”h]”hŒbUn’etichetta ci può dire quale commit ha introdotto il problema che viene corretto nella patch:”…””}”(hj^h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´KØhj!h²hubjr)”}”(hŒiFixes: 1f2e3d4c5b6a ("The first line of the commit specified by the first 12 characters of its SHA-1 ID")”h]”hŒiFixes: 1f2e3d4c5b6a ("The first line of the commit specified by the first 12 characters of its SHA-1 ID")”…””}”hjlsbah}”(h]”h ]”h"]”h$]”h&]”jj‚uh1jqh³jh´KÚhj!h²hubh¼)”}”(hŒÿUn'altra etichetta viene usata per fornire collegamenti a pagine web contenenti maggiori informazioni, per esempio una discussione avvenuta precedentemente circa il baco risolto dalla patch, oppure un documento con le specifiche implementate dalla patch::”h]”hXUn’altra etichetta viene usata per fornire collegamenti a pagine web contenenti maggiori informazioni, per esempio una discussione avvenuta precedentemente circa il baco risolto dalla patch, oppure un documento con le specifiche implementate dalla patch:”…””}”(hjzh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´KÜhj!h²hubjr)”}”(hŒ>Link: https://example.com/somewhere.html optional-other-stuff”h]”hŒ>Link: https://example.com/somewhere.html optional-other-stuff”…””}”hjˆsbah}”(h]”h ]”h"]”h$]”h&]”jj‚uh1jqh³jh´Káhj!h²hubh¼)”}”(hX$Alcuni manutentori aggiungono quest'etichetta alla patch per fare riferimento alla più recente discussione pubblica. A volte questo è fatto automaticamente da alcuni strumenti come b4 or un *hook* git come quello descritto qui 'Documentation/translations/it_IT/maintainer/configure-git.rst'”h]”(hŒÂAlcuni manutentori aggiungono quest’etichetta alla patch per fare riferimento alla più recente discussione pubblica. A volte questo è fatto automaticamente da alcuni strumenti come b4 or un ”…””}”(hj–h²hh³Nh´Nubj²)”}”(hŒ*hook*”h]”hŒhook”…””}”(hjžh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j±hj–ubhŒb git come quello descritto qui ‘Documentation/translations/it_IT/maintainer/configure-git.rst’”…””}”(hj–h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´Kãhj!h²hubh¼)”}”(hŒsSe il collegamento indirizza verso un rapporto su un baco risolto dalla patch, allora usate l'etichetta "Closes:"::”h]”hŒxSe il collegamento indirizza verso un rapporto su un baco risolto dalla patch, allora usate l’etichetta “Closes:â€:”…””}”(hj¶h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´Kéhj!h²hubjr)”}”(hŒ=Closes: https://example.com/issues/1234 optional-other-stuff”h]”hŒ=Closes: https://example.com/issues/1234 optional-other-stuff”…””}”hjÄsbah}”(h]”h ]”h"]”h$]”h&]”jj‚uh1jqh³jh´Kìhj!h²hubh¼)”}”(hX=Alcune piattaforme di tracciamento di bachi hanno la capacità di chiudere automaticamente il problema se l'etichetta è presente nel messaggio. Alcuni automatismi che monitorano la liste di discussione possono anche tracciare queste etichette e intraprendere azioni. Piattaforme private e URL invalidi sono proibiti.”h]”hX?Alcune piattaforme di tracciamento di bachi hanno la capacità di chiudere automaticamente il problema se l’etichetta è presente nel messaggio. Alcuni automatismi che monitorano la liste di discussione possono anche tracciare queste etichette e intraprendere azioni. Piattaforme private e URL invalidi sono proibiti.”…””}”(hjÒh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´Kîhj!h²hubh¼)”}”(hŒUn altro tipo di etichetta viene usato per indicare chi ha contribuito allo sviluppo della patch. Tutte queste etichette seguono il formato::”h]”hŒŒUn altro tipo di etichetta viene usato per indicare chi ha contribuito allo sviluppo della patch. Tutte queste etichette seguono il formato:”…””}”(hjàh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´Kôhj!h²hubjr)”}”(hŒ4tag: Full Name optional-other-stuff”h]”hŒ4tag: Full Name optional-other-stuff”…””}”hjîsbah}”(h]”h ]”h"]”h$]”h&]”jj‚uh1jqh³jh´K÷hj!h²hubh¼)”}”(hŒ%Le etichette in uso più comuni sono:”h]”hŒ%Le etichette in uso più comuni sono:”…””}”(hjüh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´Kùhj!h²hubji)”}”(hXp- Signed-off-by: questa è la certificazione che lo sviluppatore ha il diritto di sottomettere la patch per l'integrazione nel kernel. Questo rappresenta il consenso verso il certificato d'origine degli sviluppatori, il testo completo potrà essere trovato in :ref:`Documentation/translations/it_IT/process/submitting-patches.rst `. Codice che non presenta una firma appropriata non potrà essere integrato. - Co-developed-by: indica che la patch è stata cosviluppata da diversi sviluppatori; viene usato per assegnare più autori (in aggiunta a quello associato all'etichetta From:) quando più persone lavorano ad una patch. Ogni Co-developed-by: dev'essere seguito immediatamente da un Signed-off-by: del corrispondente coautore. Maggiori dettagli ed esempi sono disponibili in :ref:`Documentation/translations/it_IT/process/submitting-patches.rst `. - Acked-by: indica il consenso di un altro sviluppatore (spesso il manutentore del codice in oggetto) all'integrazione della patch nel kernel. - Tested-by: menziona la persona che ha verificato la patch e l'ha trovata funzionante. - Reviwed-by: menziona lo sviluppatore che ha revisionato la patch; per maggiori dettagli leggete la dichiarazione dei revisori in :ref:`Documentation/translations/it_IT/process/submitting-patches.rst ` - Reported-by: menziona l'utente che ha riportato il problema corretto da questa patch; quest'etichetta viene usata per dare credito alle persone che hanno verificato il codice e ci hanno fatto sapere quando le cose non funzionavano correttamente. Questa etichetta dovrebbe essere seguita da quella Closes: con un indirizzo al rapporto, a meno che questo non sia disponibile sul web. L'etichetta Link: può essere usata in alternativa a Closes: se la patch corregge solo in parte il problema riportato nel rapporto. Se esiste un rapporto disponibile sul web, allora L'etichetta dovrebbe essere seguita da un collegamento al suddetto rapporto. - Cc: la persona menzionata ha ricevuto una copia della patch ed ha avuto l'opportunità di commentarla. ”h]”jo)”}”(hhh]”(jt)”}”(hX­Signed-off-by: questa è la certificazione che lo sviluppatore ha il diritto di sottomettere la patch per l'integrazione nel kernel. Questo rappresenta il consenso verso il certificato d'origine degli sviluppatori, il testo completo potrà essere trovato in :ref:`Documentation/translations/it_IT/process/submitting-patches.rst `. Codice che non presenta una firma appropriata non potrà essere integrato. ”h]”h¼)”}”(hX¬Signed-off-by: questa è la certificazione che lo sviluppatore ha il diritto di sottomettere la patch per l'integrazione nel kernel. Questo rappresenta il consenso verso il certificato d'origine degli sviluppatori, il testo completo potrà essere trovato in :ref:`Documentation/translations/it_IT/process/submitting-patches.rst `. Codice che non presenta una firma appropriata non potrà essere integrato.”h]”(hXSigned-off-by: questa è la certificazione che lo sviluppatore ha il diritto di sottomettere la patch per l’integrazione nel kernel. Questo rappresenta il consenso verso il certificato d’origine degli sviluppatori, il testo completo potrà essere trovato in ”…””}”(hjh²hh³Nh´Nubh)”}”(hŒ]:ref:`Documentation/translations/it_IT/process/submitting-patches.rst `”h]”hÊ)”}”(hjh]”hŒ?Documentation/translations/it_IT/process/submitting-patches.rst”…””}”(hj!h²hh³Nh´Nubah}”(h]”h ]”(hÕŒstd”Œstd-ref”eh"]”h$]”h&]”uh1hÉhjubah}”(h]”h ]”h"]”h$]”h&]”Œrefdoc”h⌠refdomain”j+Œreftype”Œref”Œ refexplicit”ˆŒrefwarn”ˆhèŒit_submittingpatches”uh1hh³jh´KûhjubhŒL. Codice che non presenta una firma appropriata non potrà essere integrato.”…””}”(hjh²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´Kûhjubah}”(h]”h ]”h"]”h$]”h&]”uh1jshjubjt)”}”(hXÔCo-developed-by: indica che la patch è stata cosviluppata da diversi sviluppatori; viene usato per assegnare più autori (in aggiunta a quello associato all'etichetta From:) quando più persone lavorano ad una patch. Ogni Co-developed-by: dev'essere seguito immediatamente da un Signed-off-by: del corrispondente coautore. Maggiori dettagli ed esempi sono disponibili in :ref:`Documentation/translations/it_IT/process/submitting-patches.rst `. ”h]”h¼)”}”(hXÓCo-developed-by: indica che la patch è stata cosviluppata da diversi sviluppatori; viene usato per assegnare più autori (in aggiunta a quello associato all'etichetta From:) quando più persone lavorano ad una patch. Ogni Co-developed-by: dev'essere seguito immediatamente da un Signed-off-by: del corrispondente coautore. Maggiori dettagli ed esempi sono disponibili in :ref:`Documentation/translations/it_IT/process/submitting-patches.rst `.”h]”(hXyCo-developed-by: indica che la patch è stata cosviluppata da diversi sviluppatori; viene usato per assegnare più autori (in aggiunta a quello associato all’etichetta From:) quando più persone lavorano ad una patch. Ogni Co-developed-by: dev’essere seguito immediatamente da un Signed-off-by: del corrispondente coautore. Maggiori dettagli ed esempi sono disponibili in ”…””}”(hjQh²hh³Nh´Nubh)”}”(hŒ]:ref:`Documentation/translations/it_IT/process/submitting-patches.rst `”h]”hÊ)”}”(hj[h]”hŒ?Documentation/translations/it_IT/process/submitting-patches.rst”…””}”(hj]h²hh³Nh´Nubah}”(h]”h ]”(hÕŒstd”Œstd-ref”eh"]”h$]”h&]”uh1hÉhjYubah}”(h]”h ]”h"]”h$]”h&]”Œrefdoc”h⌠refdomain”jgŒreftype”Œref”Œ refexplicit”ˆŒrefwarn”ˆhèŒit_submittingpatches”uh1hh³jh´MhjQubhŒ.”…””}”(hjQh²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´MhjMubah}”(h]”h ]”h"]”h$]”h&]”uh1jshjubjt)”}”(hŒAcked-by: indica il consenso di un altro sviluppatore (spesso il manutentore del codice in oggetto) all'integrazione della patch nel kernel. ”h]”h¼)”}”(hŒŒAcked-by: indica il consenso di un altro sviluppatore (spesso il manutentore del codice in oggetto) all'integrazione della patch nel kernel.”h]”hŒŽAcked-by: indica il consenso di un altro sviluppatore (spesso il manutentore del codice in oggetto) all’integrazione della patch nel kernel.”…””}”(hjh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´M hj‰ubah}”(h]”h ]”h"]”h$]”h&]”uh1jshjubjt)”}”(hŒVTested-by: menziona la persona che ha verificato la patch e l'ha trovata funzionante. ”h]”h¼)”}”(hŒUTested-by: menziona la persona che ha verificato la patch e l'ha trovata funzionante.”h]”hŒWTested-by: menziona la persona che ha verificato la patch e l’ha trovata funzionante.”…””}”(hj¥h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´M hj¡ubah}”(h]”h ]”h"]”h$]”h&]”uh1jshjubjt)”}”(hŒßReviwed-by: menziona lo sviluppatore che ha revisionato la patch; per maggiori dettagli leggete la dichiarazione dei revisori in :ref:`Documentation/translations/it_IT/process/submitting-patches.rst ` ”h]”h¼)”}”(hŒÞReviwed-by: menziona lo sviluppatore che ha revisionato la patch; per maggiori dettagli leggete la dichiarazione dei revisori in :ref:`Documentation/translations/it_IT/process/submitting-patches.rst `”h]”(hŒReviwed-by: menziona lo sviluppatore che ha revisionato la patch; per maggiori dettagli leggete la dichiarazione dei revisori in ”…””}”(hj½h²hh³Nh´Nubh)”}”(hŒ]:ref:`Documentation/translations/it_IT/process/submitting-patches.rst `”h]”hÊ)”}”(hjÇh]”hŒ?Documentation/translations/it_IT/process/submitting-patches.rst”…””}”(hjÉh²hh³Nh´Nubah}”(h]”h ]”(hÕŒstd”Œstd-ref”eh"]”h$]”h&]”uh1hÉhjÅubah}”(h]”h ]”h"]”h$]”h&]”Œrefdoc”h⌠refdomain”jÓŒreftype”Œref”Œ refexplicit”ˆŒrefwarn”ˆhèŒit_submittingpatches”uh1hh³jh´Mhj½ubeh}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´Mhj¹ubah}”(h]”h ]”h"]”h$]”h&]”uh1jshjubjt)”}”(hX‚Reported-by: menziona l'utente che ha riportato il problema corretto da questa patch; quest'etichetta viene usata per dare credito alle persone che hanno verificato il codice e ci hanno fatto sapere quando le cose non funzionavano correttamente. Questa etichetta dovrebbe essere seguita da quella Closes: con un indirizzo al rapporto, a meno che questo non sia disponibile sul web. L'etichetta Link: può essere usata in alternativa a Closes: se la patch corregge solo in parte il problema riportato nel rapporto. Se esiste un rapporto disponibile sul web, allora L'etichetta dovrebbe essere seguita da un collegamento al suddetto rapporto. ”h]”(h¼)”}”(hXReported-by: menziona l'utente che ha riportato il problema corretto da questa patch; quest'etichetta viene usata per dare credito alle persone che hanno verificato il codice e ci hanno fatto sapere quando le cose non funzionavano correttamente. Questa etichetta dovrebbe essere seguita da quella Closes: con un indirizzo al rapporto, a meno che questo non sia disponibile sul web. L'etichetta Link: può essere usata in alternativa a Closes: se la patch corregge solo in parte il problema riportato nel rapporto.”h]”hXReported-by: menziona l’utente che ha riportato il problema corretto da questa patch; quest’etichetta viene usata per dare credito alle persone che hanno verificato il codice e ci hanno fatto sapere quando le cose non funzionavano correttamente. Questa etichetta dovrebbe essere seguita da quella Closes: con un indirizzo al rapporto, a meno che questo non sia disponibile sul web. L’etichetta Link: può essere usata in alternativa a Closes: se la patch corregge solo in parte il problema riportato nel rapporto.”…””}”(hjõh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´Mhjñubh¼)”}”(hŒ~Se esiste un rapporto disponibile sul web, allora L'etichetta dovrebbe essere seguita da un collegamento al suddetto rapporto.”h]”hŒ€Se esiste un rapporto disponibile sul web, allora L’etichetta dovrebbe essere seguita da un collegamento al suddetto rapporto.”…””}”(hjh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´Mhjñubeh}”(h]”h ]”h"]”h$]”h&]”uh1jshjubjt)”}”(hŒgCc: la persona menzionata ha ricevuto una copia della patch ed ha avuto l'opportunità di commentarla. ”h]”h¼)”}”(hŒfCc: la persona menzionata ha ricevuto una copia della patch ed ha avuto l'opportunità di commentarla.”h]”hŒhCc: la persona menzionata ha ricevuto una copia della patch ed ha avuto l’opportunità di commentarla.”…””}”(hjh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´Mhjubah}”(h]”h ]”h"]”h$]”h&]”uh1jshjubeh}”(h]”h ]”h"]”h$]”h&]”jïjðuh1jnh³jh´Kûhj ubah}”(h]”h ]”h"]”h$]”h&]”uh1jhh³jh´Kûhj!h²hubh¼)”}”(hX+State attenti ad aggiungere queste etichette alla vostra patch: solo "Cc:" può essere aggiunta senza il permesso esplicito della persona menzionata. Il più delle volte anche Reported-by: va bene, ma è sempre meglio chiedere specialmente se il baco è stato riportato in una comunicazione privata.”h]”hX/State attenti ad aggiungere queste etichette alla vostra patch: solo “Cc:†può essere aggiunta senza il permesso esplicito della persona menzionata. Il più delle volte anche Reported-by: va bene, ma è sempre meglio chiedere specialmente se il baco è stato riportato in una comunicazione privata.”…””}”(hj;h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´M"hj!h²hubeh}”(h]”Œ'formattazione-delle-patch-e-i-changelog”ah ]”h"]”Œ'formattazione delle patch e i changelog”ah$]”h&]”uh1j©hj«h²hh³jh´K”ubjª)”}”(hhh]”(j¯)”}”(hŒInviare la modifica”h]”hŒInviare la modifica”…””}”(hjTh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j®hjQh²hh³jh´M(ubh¼)”}”(hŒ`Prima di inviare la vostra patch, ci sarebbero ancora un paio di cose di cui dovreste aver cura:”h]”hŒ`Prima di inviare la vostra patch, ci sarebbero ancora un paio di cose di cui dovreste aver cura:”…””}”(hjbh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´M*hjQh²hubji)”}”(hXü- Siete sicuri che il vostro programma di posta non corromperà le patch? Le patch che hanno spazi bianchi in libertà o andate a capo aggiunti dai programmi di posta non funzioneranno per chi le riceve, e spesso non verranno nemmeno esaminate in dettaglio. Se avete un qualsiasi dubbio, inviate la patch a voi stessi e verificate che sia integra. :ref:`Documentation/translations/it_IT/process/email-clients.rst ` contiene alcuni suggerimenti utili sulla configurazione dei programmi di posta al fine di inviare patch. - Siete sicuri che la vostra patch non contenga sciocchi errori? Dovreste sempre processare le patch con scripts/checkpatch.pl e correggere eventuali problemi riportati. Per favore tenete ben presente che checkpatch.pl non è più intelligente di voi, nonostante sia il risultato di un certa quantità di ragionamenti su come debba essere una patch per il kernel. Se seguire i suggerimenti di checkpatch.pl rende il codice peggiore, allora non fatelo. ”h]”jo)”}”(hhh]”(jt)”}”(hXSiete sicuri che il vostro programma di posta non corromperà le patch? Le patch che hanno spazi bianchi in libertà o andate a capo aggiunti dai programmi di posta non funzioneranno per chi le riceve, e spesso non verranno nemmeno esaminate in dettaglio. Se avete un qualsiasi dubbio, inviate la patch a voi stessi e verificate che sia integra. :ref:`Documentation/translations/it_IT/process/email-clients.rst ` contiene alcuni suggerimenti utili sulla configurazione dei programmi di posta al fine di inviare patch. ”h]”(h¼)”}”(hXZSiete sicuri che il vostro programma di posta non corromperà le patch? Le patch che hanno spazi bianchi in libertà o andate a capo aggiunti dai programmi di posta non funzioneranno per chi le riceve, e spesso non verranno nemmeno esaminate in dettaglio. Se avete un qualsiasi dubbio, inviate la patch a voi stessi e verificate che sia integra.”h]”hXZSiete sicuri che il vostro programma di posta non corromperà le patch? Le patch che hanno spazi bianchi in libertà o andate a capo aggiunti dai programmi di posta non funzioneranno per chi le riceve, e spesso non verranno nemmeno esaminate in dettaglio. Se avete un qualsiasi dubbio, inviate la patch a voi stessi e verificate che sia integra.”…””}”(hj{h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´M-hjwubh¼)”}”(hŒ½:ref:`Documentation/translations/it_IT/process/email-clients.rst ` contiene alcuni suggerimenti utili sulla configurazione dei programmi di posta al fine di inviare patch.”h]”(h)”}”(hŒT:ref:`Documentation/translations/it_IT/process/email-clients.rst `”h]”hÊ)”}”(hjh]”hŒ:Documentation/translations/it_IT/process/email-clients.rst”…””}”(hj‘h²hh³Nh´Nubah}”(h]”h ]”(hÕŒstd”Œstd-ref”eh"]”h$]”h&]”uh1hÉhjubah}”(h]”h ]”h"]”h$]”h&]”Œrefdoc”h⌠refdomain”j›Œreftype”Œref”Œ refexplicit”ˆŒrefwarn”ˆhèŒit_email_clients”uh1hh³jh´M3hj‰ubhŒi contiene alcuni suggerimenti utili sulla configurazione dei programmi di posta al fine di inviare patch.”…””}”(hj‰h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´M3hjwubeh}”(h]”h ]”h"]”h$]”h&]”uh1jshjtubjt)”}”(hXÅSiete sicuri che la vostra patch non contenga sciocchi errori? Dovreste sempre processare le patch con scripts/checkpatch.pl e correggere eventuali problemi riportati. Per favore tenete ben presente che checkpatch.pl non è più intelligente di voi, nonostante sia il risultato di un certa quantità di ragionamenti su come debba essere una patch per il kernel. Se seguire i suggerimenti di checkpatch.pl rende il codice peggiore, allora non fatelo. ”h]”h¼)”}”(hXÄSiete sicuri che la vostra patch non contenga sciocchi errori? Dovreste sempre processare le patch con scripts/checkpatch.pl e correggere eventuali problemi riportati. Per favore tenete ben presente che checkpatch.pl non è più intelligente di voi, nonostante sia il risultato di un certa quantità di ragionamenti su come debba essere una patch per il kernel. Se seguire i suggerimenti di checkpatch.pl rende il codice peggiore, allora non fatelo.”h]”hXÄSiete sicuri che la vostra patch non contenga sciocchi errori? Dovreste sempre processare le patch con scripts/checkpatch.pl e correggere eventuali problemi riportati. Per favore tenete ben presente che checkpatch.pl non è più intelligente di voi, nonostante sia il risultato di un certa quantità di ragionamenti su come debba essere una patch per il kernel. Se seguire i suggerimenti di checkpatch.pl rende il codice peggiore, allora non fatelo.”…””}”(hjÁh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´M7hj½ubah}”(h]”h ]”h"]”h$]”h&]”uh1jshjtubeh}”(h]”h ]”h"]”h$]”h&]”jïjðuh1jnh³jh´M-hjpubah}”(h]”h ]”h"]”h$]”h&]”uh1jhh³jh´M-hjQh²hubh¼)”}”(hXLe patch dovrebbero essere sempre inviate come testo puro. Per favore non inviatele come allegati; questo rende molto più difficile, per i revisori, citare parti della patch che si vogliono commentare. Invece, mettete la vostra patch direttamente nel messaggio.”h]”hXLe patch dovrebbero essere sempre inviate come testo puro. Per favore non inviatele come allegati; questo rende molto più difficile, per i revisori, citare parti della patch che si vogliono commentare. Invece, mettete la vostra patch direttamente nel messaggio.”…””}”(hjáh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´M>hjQh²hubh¼)”}”(hXjQuando inviate le patch, è importante inviarne una copia a tutte le persone che potrebbero esserne interessate. Al contrario di altri progetti, il kernel incoraggia le persone a peccare nell'invio di tante copie; non presumente che le persone interessate vedano i vostri messaggi sulla lista di discussione. In particolare le copie dovrebbero essere inviate a:”h]”hXlQuando inviate le patch, è importante inviarne una copia a tutte le persone che potrebbero esserne interessate. Al contrario di altri progetti, il kernel incoraggia le persone a peccare nell’invio di tante copie; non presumente che le persone interessate vedano i vostri messaggi sulla lista di discussione. In particolare le copie dovrebbero essere inviate a:”…””}”(hjïh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´MChjQh²hubji)”}”(hX-- I manutentori dei sottosistemi affetti della modifica. Come descritto in precedenza, il file MAINTAINERS è il primo luogo dove cercare i nomi di queste persone. - Altri sviluppatori che hanno lavorato nello stesso ambiente - specialmente quelli che potrebbero lavorarci proprio ora. Usate git potrebbe essere utile per vedere chi altri ha modificato i file su cui state lavorando. - Se state rispondendo a un rapporto su un baco, o a una richiesta di funzionalità, includete anche gli autori di quei rapporti/richieste. - Inviate una copia alle liste di discussione interessate, o, se nient'altro è adatto, alla lista linux-kernel - Se state correggendo un baco, pensate se la patch dovrebbe essere inclusa nel prossimo rilascio stabile. Se è così, la lista di discussione stable@vger.kernel.org dovrebbe riceverne una copia. Aggiungete anche l'etichetta "Cc: stable@vger.kernel.org" nella patch stessa; questo permetterà alla squadra *stable* di ricevere una notifica quando questa correzione viene integrata nel ramo principale. ”•¬-h]”jo)”}”(hhh]”(jt)”}”(hŒ£I manutentori dei sottosistemi affetti della modifica. Come descritto in precedenza, il file MAINTAINERS è il primo luogo dove cercare i nomi di queste persone. ”h]”h¼)”}”(hŒ¢I manutentori dei sottosistemi affetti della modifica. Come descritto in precedenza, il file MAINTAINERS è il primo luogo dove cercare i nomi di queste persone.”h]”hŒ¢I manutentori dei sottosistemi affetti della modifica. Come descritto in precedenza, il file MAINTAINERS è il primo luogo dove cercare i nomi di queste persone.”…””}”(hjh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´MIhjubah}”(h]”h ]”h"]”h$]”h&]”uh1jshjubjt)”}”(hŒÛAltri sviluppatori che hanno lavorato nello stesso ambiente - specialmente quelli che potrebbero lavorarci proprio ora. Usate git potrebbe essere utile per vedere chi altri ha modificato i file su cui state lavorando. ”h]”h¼)”}”(hŒÚAltri sviluppatori che hanno lavorato nello stesso ambiente - specialmente quelli che potrebbero lavorarci proprio ora. Usate git potrebbe essere utile per vedere chi altri ha modificato i file su cui state lavorando.”h]”hŒÚAltri sviluppatori che hanno lavorato nello stesso ambiente - specialmente quelli che potrebbero lavorarci proprio ora. Usate git potrebbe essere utile per vedere chi altri ha modificato i file su cui state lavorando.”…””}”(hj h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´MMhjubah}”(h]”h ]”h"]”h$]”h&]”uh1jshjubjt)”}”(hŒŠSe state rispondendo a un rapporto su un baco, o a una richiesta di funzionalità, includete anche gli autori di quei rapporti/richieste. ”h]”h¼)”}”(hŒ‰Se state rispondendo a un rapporto su un baco, o a una richiesta di funzionalità, includete anche gli autori di quei rapporti/richieste.”h]”hŒ‰Se state rispondendo a un rapporto su un baco, o a una richiesta di funzionalità, includete anche gli autori di quei rapporti/richieste.”…””}”(hj8h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´MQhj4ubah}”(h]”h ]”h"]”h$]”h&]”uh1jshjubjt)”}”(hŒnInviate una copia alle liste di discussione interessate, o, se nient'altro è adatto, alla lista linux-kernel ”h]”h¼)”}”(hŒmInviate una copia alle liste di discussione interessate, o, se nient'altro è adatto, alla lista linux-kernel”h]”hŒoInviate una copia alle liste di discussione interessate, o, se nient’altro è adatto, alla lista linux-kernel”…””}”(hjPh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´MThjLubah}”(h]”h ]”h"]”h$]”h&]”uh1jshjubjt)”}”(hX“Se state correggendo un baco, pensate se la patch dovrebbe essere inclusa nel prossimo rilascio stabile. Se è così, la lista di discussione stable@vger.kernel.org dovrebbe riceverne una copia. Aggiungete anche l'etichetta "Cc: stable@vger.kernel.org" nella patch stessa; questo permetterà alla squadra *stable* di ricevere una notifica quando questa correzione viene integrata nel ramo principale. ”h]”h¼)”}”(hX’Se state correggendo un baco, pensate se la patch dovrebbe essere inclusa nel prossimo rilascio stabile. Se è così, la lista di discussione stable@vger.kernel.org dovrebbe riceverne una copia. Aggiungete anche l'etichetta "Cc: stable@vger.kernel.org" nella patch stessa; questo permetterà alla squadra *stable* di ricevere una notifica quando questa correzione viene integrata nel ramo principale.”h]”(hŒSe state correggendo un baco, pensate se la patch dovrebbe essere inclusa nel prossimo rilascio stabile. Se è così, la lista di discussione ”…””}”(hjhh²hh³Nh´Nubjn)”}”(hŒstable@vger.kernel.org”h]”hŒstable@vger.kernel.org”…””}”(hjph²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”Œrefuri”Œmailto:stable@vger.kernel.org”uh1jmhjhubhŒF dovrebbe riceverne una copia. Aggiungete anche l’etichetta “Cc: ”…””}”(hjhh²hh³Nh´Nubjn)”}”(hŒstable@vger.kernel.org”h]”hŒstable@vger.kernel.org”…””}”(hj„h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”Œrefuri”Œmailto:stable@vger.kernel.org”uh1jmhjhubhŒ8†nella patch stessa; questo permetterà alla squadra ”…””}”(hjhh²hh³Nh´Nubj²)”}”(hŒ*stable*”h]”hŒstable”…””}”(hj˜h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j±hjhubhŒW di ricevere una notifica quando questa correzione viene integrata nel ramo principale.”…””}”(hjhh²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´MWhjdubah}”(h]”h ]”h"]”h$]”h&]”uh1jshjubeh}”(h]”h ]”h"]”h$]”h&]”jïjðuh1jnh³jh´MIhjýubah}”(h]”h ]”h"]”h$]”h&]”uh1jhh³jh´MIhjQh²hubh¼)”}”(hXMQuando scegliete i destinatari della patch, è bene avere un'idea di chi pensiate che sia colui che, eventualmente, accetterà la vostra patch e la integrerà. Nonostante sia possibile inviare patch direttamente a Linus Torvalds, e lasciare che sia lui ad integrarle,solitamente non è la strada migliore da seguire. Linus è occupato, e ci sono dei manutentori di sotto-sistema che controllano una parte specifica del kernel. Solitamente, vorreste che siano questi manutentori ad integrare le vostre patch. Se non c'è un chiaro manutentore, l'ultima spiaggia è spesso Andrew Morton.”h]”hXSQuando scegliete i destinatari della patch, è bene avere un’idea di chi pensiate che sia colui che, eventualmente, accetterà la vostra patch e la integrerà. Nonostante sia possibile inviare patch direttamente a Linus Torvalds, e lasciare che sia lui ad integrarle,solitamente non è la strada migliore da seguire. Linus è occupato, e ci sono dei manutentori di sotto-sistema che controllano una parte specifica del kernel. Solitamente, vorreste che siano questi manutentori ad integrare le vostre patch. Se non c’è un chiaro manutentore, l’ultima spiaggia è spesso Andrew Morton.”…””}”(hjÂh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´M^hjQh²hubh¼)”}”(hŒoLe patch devono avere anche un buon oggetto. Il tipico formato per l'oggetto di una patch assomiglia a questo:”h]”hŒqLe patch devono avere anche un buon oggetto. Il tipico formato per l’oggetto di una patch assomiglia a questo:”…””}”(hjÐh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´MghjQh²hubjr)”}”(hŒ7[PATCH nn/mm] subsys: one-line description of the patch”h]”hŒ7[PATCH nn/mm] subsys: one-line description of the patch”…””}”hjÞsbah}”(h]”h ]”h"]”h$]”h&]”jj‚uh1jqh³jh´MlhjQh²hubh¼)”}”(hŒædove "nn" è il numero ordinale della patch, "mm" è il numero totale delle patch nella serie, e "subsys" è il nome del sottosistema interessato. Chiaramente, nn/mm può essere omesso per una serie composta da una singola patch.”h]”hŒòdove “nn†è il numero ordinale della patch, “mm†è il numero totale delle patch nella serie, e “subsys†è il nome del sottosistema interessato. Chiaramente, nn/mm può essere omesso per una serie composta da una singola patch.”…””}”(hjìh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´MnhjQh²hubh¼)”}”(hX\Se avete una significative serie di patch, è prassi inviare una descrizione introduttiva come parte zero. Tuttavia questa convenzione non è universalmente seguita; se la usate, ricordate che le informazioni nell'introduzione non faranno parte del changelog del kernel. Quindi per favore, assicuratevi che ogni patch abbia un changelog completo.”h]”hX^Se avete una significative serie di patch, è prassi inviare una descrizione introduttiva come parte zero. Tuttavia questa convenzione non è universalmente seguita; se la usate, ricordate che le informazioni nell’introduzione non faranno parte del changelog del kernel. Quindi per favore, assicuratevi che ogni patch abbia un changelog completo.”…””}”(hjúh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´MrhjQh²hubh¼)”}”(hX©In generale, la seconda parte e quelle successive di una patch "composta" dovrebbero essere inviate come risposta alla prima, cosicché vengano viste come un unico *thread*. Strumenti come git e quilt hanno comandi per inviare gruppi di patch con la struttura appropriata. Se avete una serie lunga e state usando git, per favore state alla larga dall'opzione --chain-reply-to per evitare di creare un annidamento eccessivo.”h]”(hŒ¨In generale, la seconda parte e quelle successive di una patch “composta†dovrebbero essere inviate come risposta alla prima, cosicché vengano viste come un unico ”…””}”(hj h²hh³Nh´Nubj²)”}”(hŒ*thread*”h]”hŒthread”…””}”(hj h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j±hj ubhŒÿ. Strumenti come git e quilt hanno comandi per inviare gruppi di patch con la struttura appropriata. Se avete una serie lunga e state usando git, per favore state alla larga dall’opzione --chain-reply-to per evitare di creare un annidamento eccessivo.”…””}”(hj h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1h»h³jh´MxhjQh²hubeh}”(h]”Œinviare-la-modifica”ah ]”h"]”Œinviare la modifica”ah$]”h&]”uh1j©hj«h²hh³jh´M(ubeh}”(h]”(Œpubblicare-modifiche”j¨eh ]”h"]”(Œpubblicare modifiche”Œit_development_posting”eh$]”h&]”uh1j©hhh²hh³jh´K Œexpect_referenced_by_name”}”j6 jsŒexpect_referenced_by_id”}”j¨jsubeh}”(h]”h ]”h"]”h$]”h&]”Œsource”juh1hŒcurrent_source”NŒ current_line”NŒsettings”Œdocutils.frontend”ŒValues”“”)”}”(j®NŒ generator”NŒ datestamp”NŒ source_link”NŒ source_url”NŒ toc_backlinks”Œentry”Œfootnote_backlinks”KŒ sectnum_xform”KŒstrip_comments”NŒstrip_elements_with_classes”NŒ strip_classes”NŒ report_level”KŒ halt_level”KŒexit_status_level”KŒdebug”NŒwarning_stream”NŒ traceback”ˆŒinput_encoding”Œ utf-8-sig”Œinput_encoding_error_handler”Œstrict”Œoutput_encoding”Œutf-8”Œoutput_encoding_error_handler”j` Œerror_encoding”Œutf-8”Œerror_encoding_error_handler”Œbackslashreplace”Œ language_code”Œen”Œrecord_dependencies”NŒconfig”NŒ id_prefix”hŒauto_id_prefix”Œid”Œ dump_settings”NŒdump_internals”NŒdump_transforms”NŒdump_pseudo_xml”NŒexpose_internals”NŒstrict_visitor”NŒ_disable_config”NŒ_source”jŒ _destination”NŒ _config_files”]”Œ7/var/lib/git/docbuild/linux/Documentation/docutils.conf”aŒfile_insertion_enabled”ˆŒ raw_enabled”KŒline_length_limit”M'Œpep_references”NŒ pep_base_url”Œhttps://peps.python.org/”Œpep_file_url_template”Œpep-%04d”Œrfc_references”NŒ rfc_base_url”Œ&https://datatracker.ietf.org/doc/html/”Œ tab_width”KŒtrim_footnote_reference_space”‰Œsyntax_highlight”Œlong”Œ smart_quotes”ˆŒsmartquotes_locales”]”Œcharacter_level_inline_markup”‰Œdoctitle_xform”‰Œ docinfo_xform”KŒsectsubtitle_xform”‰Œ image_loading”Œlink”Œembed_stylesheet”‰Œcloak_email_addresses”ˆŒsection_self_link”‰Œenv”NubŒreporter”NŒindirect_targets”]”Œsubstitution_defs”}”Œsubstitution_names”}”Œrefnames”}”Œrefids”}”j¨]”jasŒnameids”}”(j6 j¨j5 j2 jFjCj jjjjNjKj- j* uŒ nametypes”}”(j6 ˆj5 ‰jF‰j ‰j‰jN‰j- ‰uh}”(j¨j«j2 j«jCjjjIjj jKj!j* jQuŒ footnote_refs”}”Œ citation_refs”}”Œ autofootnotes”]”Œautofootnote_refs”]”Œsymbol_footnotes”]”Œsymbol_footnote_refs”]”Œ footnotes”]”Œ citations”]”Œautofootnote_start”KŒsymbol_footnote_start”KŒ id_counter”Œ collections”ŒCounter”“”}”…”R”Œparse_messages”]”Œtransform_messages”]”hŒsystem_message”“”)”}”(hhh]”h¼)”}”(hhh]”hŒ