doc:it_IT: align Italian documentation · tjh.dev/kernel@1a0e2cd

+44

Documentation/translations/it_IT/doc-guide/kernel-doc.rst

··· 370 370 */ 371 371 typedef void (*type_name)(struct v4l2_ctrl *arg1, void *arg2); 372 372 373 + Documentazione di macro simili a oggetti 374 + ---------------------------------------- 375 + 376 + Le macro simili a oggetti si distinguono dalle macro simili a funzione. Esse si 377 + distinguono in base al fatto che il nome della macro simile a funzione sia 378 + immediatamente seguito da una parentesi sinistra ('(') mentre in quelle simili a 379 + oggetti no. 380 + 381 + Le macro simili a funzioni sono gestite come funzioni da ``scripts/kernel-doc``. 382 + Possono avere un elenco di parametri. Le macro simili a oggetti non hanno un 383 + elenco di parametri. 384 + 385 + Il formato generale di un commento kernel-doc per una macro simile a oggetti è:: 386 + 387 + /** 388 + * define object_name - Brief description. 389 + * 390 + * Description of the object. 391 + */ 392 + 393 + Esempio:: 394 + 395 + /** 396 + * define MAX_ERRNO - maximum errno value that is supported 397 + * 398 + * Kernel pointers have redundant information, so we can use a 399 + * scheme where we can return either an error code or a normal 400 + * pointer with the same return value. 401 + */ 402 + #define MAX_ERRNO 4095 403 + 404 + Esempio:: 405 + 406 + /** 407 + * define DRM_GEM_VRAM_PLANE_HELPER_FUNCS - \ 408 + * Initializes struct drm_plane_helper_funcs for VRAM handling 409 + * 410 + * This macro initializes struct drm_plane_helper_funcs to use the 411 + * respective helper functions. 412 + */ 413 + #define DRM_GEM_VRAM_PLANE_HELPER_FUNCS \ 414 + .prepare_fb = drm_gem_vram_plane_helper_prepare_fb, \ 415 + .cleanup_fb = drm_gem_vram_plane_helper_cleanup_fb 416 + 373 417 Marcatori e riferimenti 374 418 ----------------------- 375 419

+1 -1

Documentation/translations/it_IT/doc-guide/parse-headers.rst

··· 63 63 *********** 64 64 65 65 Converte un file d'intestazione o un file sorgente C (C_FILE) in un testo 66 - ReStructuredText incluso mediante il blocco ..parsed-literal 66 + reStructuredText incluso mediante il blocco ..parsed-literal 67 67 con riferimenti alla documentazione che descrive l'API. Opzionalmente, 68 68 il programma accetta anche un altro file (EXCEPTIONS_FILE) che 69 69 descrive quali elementi debbano essere ignorati o il cui riferimento

+23 -4

Documentation/translations/it_IT/process/5.Posting.rst

··· 223 223 Fixes: 1f2e3d4c5b6a ("The first line of the commit specified by the first 12 characters of its SHA-1 ID") 224 224 225 225 Un'altra etichetta viene usata per fornire collegamenti a pagine web contenenti 226 - maggiori informazioni, per esempio un rapporto circa il baco risolto dalla 227 - patch, oppure un documento con le specifiche implementate dalla patch:: 226 + maggiori informazioni, per esempio una discussione avvenuta precedentemente 227 + circa il baco risolto dalla patch, oppure un documento con le specifiche 228 + implementate dalla patch:: 228 229 229 230 Link: https://example.com/somewhere.html optional-other-stuff 230 231 ··· 234 233 alcuni strumenti come b4 or un *hook* git come quello descritto qui 235 234 'Documentation/translations/it_IT/maintainer/configure-git.rst' 236 235 237 - Un terzo tipo di etichetta viene usato per indicare chi ha contribuito allo 236 + 237 + Se il collegamento indirizza verso un rapporto su un baco risolto dalla patch, 238 + allora usate l'etichetta "Closes:":: 239 + 240 + Closes: https://example.com/issues/1234 optional-other-stuff 241 + 242 + Alcune piattaforme di tracciamento di bachi hanno la capacità di chiudere 243 + automaticamente il problema se l'etichetta è presente nel messaggio. Alcuni 244 + automatismi che monitorano la liste di discussione possono anche tracciare 245 + queste etichette e intraprendere azioni. Piattaforme private e URL invalidi sono 246 + proibiti. 247 + 248 + Un altro tipo di etichetta viene usato per indicare chi ha contribuito allo 238 249 sviluppo della patch. Tutte queste etichette seguono il formato:: 239 250 240 251 tag: Full Name <email address> optional-other-stuff ··· 280 267 - Reported-by: menziona l'utente che ha riportato il problema corretto da 281 268 questa patch; quest'etichetta viene usata per dare credito alle persone che 282 269 hanno verificato il codice e ci hanno fatto sapere quando le cose non 283 - funzionavano correttamente. Se esiste un rapporto disponibile sul web, allora 270 + funzionavano correttamente. Questa etichetta dovrebbe essere seguita da 271 + quella Closes: con un indirizzo al rapporto, a meno che questo non sia 272 + disponibile sul web. L'etichetta Link: può essere usata in alternativa a 273 + Closes: se la patch corregge solo in parte il problema riportato nel 274 + rapporto. 275 + 276 + Se esiste un rapporto disponibile sul web, allora 284 277 L'etichetta dovrebbe essere seguita da un collegamento al suddetto rapporto. 285 278 286 279 - Cc: la persona menzionata ha ricevuto una copia della patch ed ha avuto

+7

Documentation/translations/it_IT/process/6.Followthrough.rst

··· 60 60 stanno lavorando per la creazione del miglior kernel possibile; non 61 61 stanno cercando di creare un disagio ad aziende concorrenti. 62 62 63 + - Preparatevi a richieste apparentemente sciocche di modifiche allo stile di 64 + codifica e a richieste di trasferire parte del vostro codice in parti 65 + condivise del kernel. Uno dei compiti dei manutentori è quello di mantenere 66 + lo aspetto del codice. A volte questo significa che l'ingegnoso stratagemma 67 + nel vostro driver per aggirare un problema deve diventare una caratteristica 68 + generalizzata del kernel pronta per essere riutilizzata. 69 + 63 70 Quello che si sta cercando di dire è che, quando i revisori vi inviano degli 64 71 appunti dovete fare attenzione alle osservazioni tecniche che vi stanno 65 72 facendo. Non lasciate che il loro modo di esprimersi o il vostro orgoglio

+2 -2

Documentation/translations/it_IT/process/changes.rst

··· 33 33 Programma Versione minima Comando per verificare la versione 34 34 ====================== ================= ======================================== 35 35 GNU C 5.1 gcc --version 36 - Clang/LLVM (optional) 11.0.0 clang --version 37 - Rust (opzionale) 1.74.1 rustc --version 36 + Clang/LLVM (optional) 13.0.0 clang --version 37 + Rust (opzionale) 1.76.0 rustc --version 38 38 bindgen (opzionale) 0.65.1 bindgen --version 39 39 GNU make 3.81 make --version 40 40 bash 4.2 bash --version

+1 -1

Documentation/translations/it_IT/process/index.rst

··· 107 107 108 108 magic-number 109 109 clang-format 110 - ../riscv/patch-acceptance 110 + ../arch/riscv/patch-acceptance 111 111 112 112 .. only:: subproject and html 113 113

+174 -148

Documentation/translations/it_IT/process/stable-kernel-rules.rst

··· 11 11 Regole sul tipo di patch che vengono o non vengono accettate nei sorgenti 12 12 "-stable": 13 13 14 - - Ovviamente dev'essere corretta e verificata. 15 - - Non dev'essere più grande di 100 righe, incluso il contesto. 16 - - Deve correggere una cosa sola. 17 - - Deve correggere un baco vero che sta disturbando gli utenti (non cose del 18 - tipo "Questo potrebbe essere un problema ..."). 19 - - Deve correggere un problema di compilazione (ma non per cose già segnate 20 - con CONFIG_BROKEN), un kernel oops, un blocco, una corruzione di dati, 21 - un vero problema di sicurezza, o problemi del tipo "oh, questo non va bene". 22 - In pratica, qualcosa di critico. 23 - - Problemi importanti riportati dagli utenti di una distribuzione potrebbero 24 - essere considerati se correggono importanti problemi di prestazioni o di 25 - interattività. Dato che questi problemi non sono così ovvi e la loro 26 - correzione ha un'alta probabilità d'introdurre una regressione, dovrebbero 27 - essere sottomessi solo dal manutentore della distribuzione includendo un 28 - link, se esiste, ad un rapporto su bugzilla, e informazioni aggiuntive 29 - sull'impatto che ha sugli utenti. 30 - - Non deve correggere problemi relativi a una "teorica sezione critica", 31 - a meno che non venga fornita anche una spiegazione su come questa si 32 - possa verificare. 33 - - Non deve includere alcuna correzione "banale" (correzioni grammaticali, 34 - pulizia dagli spazi bianchi, eccetera). 35 - - Deve rispettare le regole scritte in 36 - :ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>` 37 - - Questa patch o una equivalente deve esistere già nei sorgenti principali di 38 - Linux 14 + - Questa patch o una equivalente deve esistere già nei sorgenti principali di 15 + Linux (upstream) 16 + - Ovviamente dev'essere corretta e verificata. 17 + - Non dev'essere più grande di 100 righe, incluso il contesto. 18 + - Deve rispettare le regole scritte in 19 + :ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>` 20 + - Deve correggere un vero baco che causi problemi agli utenti oppure aggiunge 21 + un nuovo identificatore di dispositivo. Maggiori dettagli per il primo caso: 39 22 23 + - Corregge un problema come un oops, un blocco, una corruzione di dati, un 24 + vero problema di sicurezza, una stranezza hardware, un problema di 25 + compilazione (ma non per cose già segnate con CONFIG_BROKEN), o problemi 26 + del tipo "oh, questo non va bene". 27 + - Problemi importanti riportati dagli utenti di una distribuzione potrebbero 28 + essere considerati se correggono importanti problemi di prestazioni o di 29 + interattività. Dato che questi problemi non sono così ovvi e la loro 30 + correzione ha un'alta probabilità d'introdurre una regressione, 31 + dovrebbero essere sottomessi solo dal manutentore della distribuzione 32 + includendo un link, se esiste, ad un rapporto su bugzilla, e informazioni 33 + aggiuntive sull'impatto che ha sugli utenti. 34 + - Non si accettano cose del tipo "Questo potrebbe essere un problema ..." 35 + come una teorica sezione critica, senza aver fornito anche una spiegazione 36 + su come il baco possa essere sfruttato. 37 + - Non deve includere alcuna correzione "banale" (correzioni grammaticali, 38 + pulizia dagli spazi bianchi, eccetera). 40 39 41 40 Procedura per sottomettere patch per i sorgenti -stable 42 41 ------------------------------------------------------- ··· 45 46 di revisione -stable, ma dovrebbe seguire le procedure descritte in 46 47 :ref:`Documentation/translations/it_IT/process/security-bugs.rst <it_securitybugs>`. 47 48 48 - Per tutte le altre sottomissioni, scegliere una delle seguenti procedure 49 - ------------------------------------------------------------------------ 49 + Ci sono tre opzioni per inviare una modifica per i sorgenti -stable: 50 + 51 + 1. Aggiungi un'etichetta 'stable' alla descrizione della patch al momento della 52 + sottomissione per l'inclusione nei sorgenti principali. 53 + 2. Chiedere alla squadra "stable" di prendere una patch già applicata sui 54 + sorgenti principali 55 + 3. Sottomettere una patch alla squadra "stable" equivalente ad una modifica già 56 + fatta sui sorgenti principali. 57 + 58 + Le seguenti sezioni descrivono con maggiori dettagli ognuna di queste opzioni 59 + 60 + L':ref:`it_option_1` è **fortemente** raccomandata; è il modo più facile e 61 + usato. L':ref:`it_option_2` si usa quando al momento della sottomissione non si 62 + era pensato di riportare la modifica su versioni precedenti. 63 + L':ref:`it_option_3` è un'alternativa ai due metodi precedenti quando la patch 64 + nei sorgenti principali ha bisogno di aggiustamenti per essere applicata su 65 + versioni precedenti (per esempio a causa di cambiamenti dell'API). 66 + 67 + Quando si utilizza l'opzione 2 o 3 è possibile chiedere che la modifica sia 68 + inclusa in specifiche versioni stabili. In tal caso, assicurarsi che la correzione 69 + o una equivalente sia applicabile, o già presente in tutti i sorgenti 70 + stabili più recenti ancora supportati. Questo ha lo scopo di prevenire 71 + regressioni che gli utenti potrebbero incontrare in seguito durante 72 + l'aggiornamento, se ad esempio una correzione per 5.19-rc1 venisse 73 + riportata a 5.10.y, ma non a 5.15.y. 50 74 51 75 .. _it_option_1: 52 76 53 77 Opzione 1 54 78 ********* 55 79 56 - Per far sì che una patch venga automaticamente inclusa nei sorgenti stabili, 57 - aggiungete l'etichetta 80 + Aggiungete la seguente etichetta nell'area delle firme per far sì che una patch 81 + che state inviando per l'inclusione nei sorgenti principali venga presa 82 + automaticamente anche per quelli stabili:: 58 83 59 - .. code-block:: none 84 + Cc: stable@vger.kernel.org 60 85 61 - Cc: stable@vger.kernel.org 86 + Invece, usate ``Cc: stable@vger.kernel.org`` quando state inviando correzioni 87 + per vulnerabilità non ancora di pubblico dominio: questo riduce il rischio di 88 + esporre accidentalmente al pubblico la correzione quando si usa 'git 89 + send-email', perché i messaggi inviati a quell'indirizzo non vengono inviati da 90 + nessuna parte. 62 91 63 - nell'area dedicata alla firme. Una volta che la patch è stata inclusa, verrà 64 - applicata anche sui sorgenti stabili senza che l'autore o il manutentore 65 - del sottosistema debba fare qualcosa. 92 + Una volta che la patch è stata inclusa, verrà applicata anche sui sorgenti 93 + stabili senza che l'autore o il manutentore del sottosistema debba fare 94 + qualcosa. 95 + 96 + Per lasciare una nota per la squadra "stable", usate commenti in linea in stile 97 + shell (leggere oltre per maggiori dettagli). 98 + 99 + * Specificate i prerequisiti per le patch aggiuntive:: 100 + 101 + Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle 102 + Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle 103 + Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic 104 + Cc: <stable@vger.kernel.org> # 3.3.x 105 + Signed-off-by: Ingo Molnar <mingo@elte.hu> 106 + 107 + La sequenza di etichette ha il seguente significato:: 108 + 109 + git cherry-pick a1f84a3 110 + git cherry-pick 1b9508f 111 + git cherry-pick fd21073 112 + git cherry-pick <this commit> 113 + 114 + Notate che per una serie di patch non dovere elencare come necessarie tutte 115 + le patch della serie stessa. Per esempio se avete la seguente serie:: 116 + 117 + patch1 118 + patch2 119 + 120 + dove patch2 dipende da patch1, non dovete elencare patch1 come requisito per 121 + patch2 se avete già menzionato patch1 per l'inclusione in "stable" 122 + 123 + * Evidenziate le patch che hanno dei requisiti circa la versione del kernel:: 124 + 125 + Cc: <stable@vger.kernel.org> # 3.3.x 126 + 127 + L'etichetta ha il seguente significato:: 128 + 129 + git cherry-pick <this commit> 130 + 131 + per ogni sorgente "-stable" che inizia con la versione indicata. 132 + 133 + Notate che queste etichette non sono necessarie se la squadre "stable" può 134 + dedurre la versione dalle etichette Fixes: 135 + 136 + * Ritardare l'inclusione di patch:: 137 + Cc: <stable@vger.kernel.org> # after -rc3 138 + 139 + * Evidenziare problemi noti:: 140 + 141 + Cc: <stable@vger.kernel.org> # see patch description, needs adjustments for <= 6.3 142 + 143 + Esiste un'ulteriore variante per l'etichetta "stable" che permette di comunicare 144 + allo strumento di *backporting* di ignorare un cambiamento:: 145 + 146 + Cc: <stable+noautosel@kernel.org> # reason goes here, and must be present 147 + 66 148 67 149 .. _it_option_2: 68 150 69 151 Opzione 2 70 152 ********* 71 153 72 - Dopo che la patch è stata inclusa nei sorgenti Linux, inviate una mail a 154 + Se la patch è già stata inclusa nei sorgenti Linux, inviate una mail a 73 155 stable@vger.kernel.org includendo: il titolo della patch, l'identificativo 74 - del commit, il perché pensate che debba essere applicata, e in quale versione 156 + del commit, il perché pensate che debba essere applicata, e in quali versioni 75 157 del kernel la vorreste vedere. 76 158 77 159 .. _it_option_3: ··· 160 80 Opzione 3 161 81 ********* 162 82 163 - Inviata la patch, dopo aver verificato che rispetta le regole descritte in 164 - precedenza, a stable@vger.kernel.org. Dovete annotare nel changelog 165 - l'identificativo del commit nei sorgenti principali, così come la versione 166 - del kernel nel quale vorreste vedere la patch. 167 - 168 - L':ref:`it_option_1` è fortemente raccomandata; è il modo più facile e usato. 169 - L':ref:`it_option_2` e l':ref:`it_option_3` sono più utili quando, al momento 170 - dell'inclusione dei sorgenti principali, si ritiene che non debbano essere 171 - incluse anche in quelli stabili (per esempio, perché si crede che si dovrebbero 172 - fare più verifiche per eventuali regressioni). L':ref:`it_option_3` è 173 - particolarmente utile se una patch dev'essere riportata su una versione 174 - precedente (per esempio la patch richiede modifiche a causa di cambiamenti di 175 - API). 176 - 177 - Notate che per l':ref:`it_option_3`, se la patch è diversa da quella nei 178 - sorgenti principali (per esempio perché è stato necessario un lavoro di 179 - adattamento) allora dev'essere ben documentata e giustificata nella descrizione 180 - della patch. 181 - 182 - L'identificativo del commit nei sorgenti principali dev'essere indicato sopra 183 - al messaggio della patch, così: 184 - 185 - .. code-block:: none 83 + Dopo aver verificato che rispetta le regole descritte in precedenza, inviata la 84 + patch a stable@vger.kernel.org facendo anche menzione delle versioni nella quale 85 + si vorrebbe applicarla. Nel farlo, dovete annotare nel changelog 86 + l'identificativo del commit nei sorgenti principali, così come la versione del 87 + kernel nel quale vorreste vedere la patch.:: 186 88 187 89 commit <sha1> upstream. 188 90 189 - o in alternativa: 190 - 191 - .. code-block:: none 91 + o in alternativa:: 192 92 193 93 [ Upstream commit <sha1> ] 194 94 195 - In aggiunta, alcune patch inviate attraverso l':ref:`it_option_1` potrebbero 196 - dipendere da altre che devo essere incluse. Questa situazione può essere 197 - indicata nel seguente modo nell'area dedicata alle firme: 95 + Se la patch inviata devia rispetto all'originale presente nei sorgenti 96 + principali (per esempio per adattarsi ad un cambiamento di API), allora questo 97 + dev'essere giustificato e dettagliato in modo chiaro nella descrizione. 198 98 199 - .. code-block:: none 99 + Dopo la sottomissione 100 + --------------------- 200 101 201 - Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle 202 - Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle 203 - Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic 204 - Cc: <stable@vger.kernel.org> # 3.3.x 205 - Signed-off-by: Ingo Molnar <mingo@elte.hu> 102 + Il mittente riceverà un ACK quando la patch è stata accettata e messa in coda, 103 + oppure un NAK se la patch è stata rigettata. La risposta potrebbe richiedere 104 + alcuni giorni in funzione dei piani dei membri della squadra "stable", 206 105 207 - La sequenza di etichette ha il seguente significato: 208 - 209 - .. code-block:: none 210 - 211 - git cherry-pick a1f84a3 212 - git cherry-pick 1b9508f 213 - git cherry-pick fd21073 214 - git cherry-pick <this commit> 215 - 216 - Inoltre, alcune patch potrebbero avere dei requisiti circa la versione del 217 - kernel. Questo può essere indicato usando il seguente formato nell'area 218 - dedicata alle firme: 219 - 220 - .. code-block:: none 221 - 222 - Cc: <stable@vger.kernel.org> # 3.3.x 223 - 224 - L'etichetta ha il seguente significato: 225 - 226 - .. code-block:: none 227 - 228 - git cherry-pick <this commit> 229 - 230 - per ogni sorgente "-stable" che inizia con la versione indicata. 231 - 232 - Dopo la sottomissione: 233 - 234 - - Il mittente riceverà un ACK quando la patch è stata accettata e messa in 235 - coda, oppure un NAK se la patch è stata rigettata. A seconda degli impegni 236 - degli sviluppatori, questa risposta potrebbe richiedere alcuni giorni. 237 - - Se accettata, la patch verrà aggiunta alla coda -stable per essere 238 - revisionata dal altri sviluppatori e dal principale manutentore del 239 - sottosistema. 240 - 106 + Se accettata, la patch verrà aggiunta alla coda -stable per essere revisionata 107 + dal altri sviluppatori e dal principale manutentore del sottosistema. 241 108 242 109 Ciclo di una revisione 243 110 ---------------------- 244 111 245 - - Quando i manutentori -stable decidono di fare un ciclo di revisione, le 246 - patch vengono mandate al comitato per la revisione, ai manutentori soggetti 247 - alle modifiche delle patch (a meno che il mittente non sia anche il 248 - manutentore di quell'area del kernel) e in CC: alla lista di discussione 249 - linux-kernel. 250 - - La commissione per la revisione ha 48 ore per dare il proprio ACK o NACK 251 - alle patch. 252 - - Se una patch viene rigettata da un membro della commissione, o un membro 253 - della lista linux-kernel obietta la bontà della patch, sollevando problemi 254 - che i manutentori ed i membri non avevano compreso, allora la patch verrà 255 - rimossa dalla coda. 256 - - Le patch che hanno ricevuto un ACK verranno inviate nuovamente come parte di 257 - un rilascio candidato (-rc) al fine di essere verificate dagli sviluppatori e 258 - dai testatori. 259 - - Solitamente si pubblica solo una -rc, tuttavia se si riscontrano problemi 260 - importanti, alcune patch potrebbero essere modificate o essere scartate, 261 - oppure nuove patch potrebbero essere messe in coda. Dunque, verranno pubblicate 262 - nuove -rc e così via finché non si ritiene che non vi siano più problemi. 263 - - Si può rispondere ad una -rc scrivendo sulla lista di discussione un'email 264 - con l'etichetta "Tested-by:". Questa etichetta verrà raccolta ed aggiunta al 265 - commit rilascio. 266 - - Alla fine del ciclo di revisione il nuovo rilascio -stable conterrà tutte le 267 - patch che erano in coda e sono state verificate. 268 - - Le patch di sicurezza verranno accettate nei sorgenti -stable direttamente 269 - dalla squadra per la sicurezza del kernel, e non passerà per il normale 270 - ciclo di revisione. Contattate la suddetta squadra per maggiori dettagli 271 - su questa procedura. 112 + - Quando i manutentori -stable decidono di fare un ciclo di revisione, le 113 + patch vengono mandate al comitato per la revisione, ai manutentori soggetti 114 + alle modifiche delle patch (a meno che il mittente non sia anche il 115 + manutentore di quell'area del kernel) e in CC: alla lista di discussione 116 + linux-kernel. 117 + - La commissione per la revisione ha 48 ore per dare il proprio ACK o NACK 118 + alle patch. 119 + - Se una patch viene rigettata da un membro della commissione, o un membro 120 + della lista linux-kernel obietta la bontà della patch, sollevando problemi 121 + che i manutentori ed i membri non avevano compreso, allora la patch verrà 122 + rimossa dalla coda. 123 + - Le patch che hanno ricevuto un ACK verranno inviate nuovamente come parte di 124 + un rilascio candidato (-rc) al fine di essere verificate dagli sviluppatori e 125 + dai testatori. 126 + - Solitamente si pubblica solo una -rc, tuttavia se si riscontrano problemi 127 + importanti, alcune patch potrebbero essere modificate o essere scartate, 128 + oppure nuove patch potrebbero essere messe in coda. Dunque, verranno pubblicate 129 + nuove -rc e così via finché non si ritiene che non vi siano più problemi. 130 + - Si può rispondere ad una -rc scrivendo sulla lista di discussione un'email 131 + con l'etichetta "Tested-by:". Questa etichetta verrà raccolta ed aggiunta al 132 + commit rilascio. 133 + - Alla fine del ciclo di revisione il nuovo rilascio -stable conterrà tutte le 134 + patch che erano in coda e sono state verificate. 135 + - Le patch di sicurezza verranno accettate nei sorgenti -stable direttamente 136 + dalla squadra per la sicurezza del kernel, e non passerà per il normale 137 + ciclo di revisione. Contattate la suddetta squadra per maggiori dettagli 138 + su questa procedura. 272 139 273 140 Sorgenti 274 141 -------- 275 142 276 - - La coda delle patch, sia quelle già applicate che in fase di revisione, 277 - possono essere trovate al seguente indirizzo: 143 + - La coda delle patch, sia quelle già applicate che in fase di revisione, 144 + possono essere trovate al seguente indirizzo: 278 145 279 - https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git 146 + https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git 280 147 281 - - Il rilascio definitivo, e marchiato, di tutti i kernel stabili può essere 282 - trovato in rami distinti per versione al seguente indirizzo: 148 + - Il rilascio definitivo, e marchiato, di tutti i kernel stabili può essere 149 + trovato in rami distinti per versione al seguente indirizzo: 283 150 284 - https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git 151 + https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git 285 152 286 - - I rilasci candidati di tutti i kernel stabili possono essere trovati al 287 - seguente indirizzo: 153 + - I rilasci candidati di tutti i kernel stabili possono essere trovati al 154 + seguente indirizzo: 288 155 289 156 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/ 290 157 291 - 292 - .. warning:: 293 - I sorgenti -stable-rc sono un'istantanea dei sorgenti stable-queue e 294 - subirà frequenti modifiche, dunque verrà anche trapiantato spesso. 295 - Dovrebbe essere usato solo allo scopo di verifica (per esempio in un 296 - sistema di CI) 158 + .. warning:: 159 + I sorgenti -stable-rc sono un'istantanea dei sorgenti stable-queue e 160 + subirà frequenti modifiche, dunque verrà anche trapiantato spesso. 161 + Dovrebbe essere usato solo allo scopo di verifica (per esempio in un 162 + sistema di CI) 297 163 298 164 Comitato per la revisione 299 165 ------------------------- 300 166 301 - - Questo comitato è fatto di sviluppatori del kernel che si sono offerti 302 - volontari per questo lavoro, e pochi altri che non sono proprio volontari. 167 + - Questo comitato è fatto di sviluppatori del kernel che si sono offerti 168 + volontari per questo lavoro, e pochi altri che non sono proprio volontari.

+109 -26

Documentation/translations/it_IT/process/submitting-patches.rst

··· 106 106 xyzzy to do frotz", come se steste dando ordini al codice di cambiare il suo 107 107 comportamento. 108 108 109 + Se volete far riferimento a uno specifico commit, non usate solo 110 + l'identificativo SHA-1. Per cortesia, aggiungete anche la breve riga 111 + riassuntiva del commit per rendere la chiaro ai revisori l'oggetto. 112 + Per esempio:: 113 + 114 + Commit e21d2170f36602ae2708 ("video: remove unnecessary 115 + platform_set_drvdata()") removed the unnecessary 116 + platform_set_drvdata(), but left the variable "dev" unused, 117 + delete it. 118 + 119 + Dovreste anche assicurarvi di usare almeno i primi 12 caratteri 120 + dell'identificativo SHA-1. Il repositorio del kernel ha *molti* oggetti e 121 + questo rende possibile la collisione fra due identificativi con pochi 122 + caratteri. Tenete ben presente che anche se oggi non ci sono collisioni con il 123 + vostro identificativo a 6 caratteri, potrebbero essercene fra 5 anni da oggi. 124 + 109 125 Se ci sono delle discussioni, o altre informazioni d'interesse, che fanno 110 126 riferimento alla patch, allora aggiungete l'etichetta 'Link:' per farvi 111 - riferimento. Per esempio, se la vostra patch corregge un baco potete aggiungere 127 + riferimento. Se la patch è il risultato di una discussione avvenuta 128 + precedentemente o di un documento sul presente sul web, allora fatevi 129 + riferimento. 130 + 131 + Per esempio, se la vostra patch corregge un baco potete aggiungere 112 132 quest'etichetta per fare riferimento ad un rapporto su una lista di discussione 113 133 o un *bug tracker*. Un altro esempio; potete usare quest'etichetta per far 114 134 riferimento ad una discussione precedentemente avvenuta su una lista di ··· 149 129 accedere alle fonti esterne. Inoltre, riassumente i punti più salienti che hanno 150 130 condotto all'invio della patch. 151 131 152 - Se volete far riferimento a uno specifico commit, non usate solo 153 - l'identificativo SHA-1. Per cortesia, aggiungete anche la breve riga 154 - riassuntiva del commit per rendere la chiaro ai revisori l'oggetto. 155 - Per esempio:: 132 + Se il collegamento indirizza verso un rapporto su un baco risolto dalla patch, 133 + allora usate l'etichetta "Closes:":: 156 134 157 - Commit e21d2170f36602ae2708 ("video: remove unnecessary 158 - platform_set_drvdata()") removed the unnecessary 159 - platform_set_drvdata(), but left the variable "dev" unused, 160 - delete it. 135 + Closes: https://example.com/issues/1234 optional-other-stuff 161 136 162 - Dovreste anche assicurarvi di usare almeno i primi 12 caratteri 163 - dell'identificativo SHA-1. Il repositorio del kernel ha *molti* oggetti e 164 - questo rende possibile la collisione fra due identificativi con pochi 165 - caratteri. Tenete ben presente che anche se oggi non ci sono collisioni con il 166 - vostro identificativo a 6 caratteri, potrebbero essercene fra 5 anni da oggi. 137 + Alcune piattaforme di tracciamento di bachi hanno la capacità di chiudere 138 + automaticamente il problema se l'etichetta è presente nel messaggio. Alcuni 139 + automatismi che monitorano la liste di discussione possono anche tracciare 140 + queste etichette e intraprendere azioni. Piattaforme private e URL invalidi sono 141 + proibiti. 167 142 168 143 Se la vostra patch corregge un baco in un commit specifico, per esempio avete 169 144 trovato un problema usando ``git bisect``, per favore usate l'etichetta ··· 252 237 5) Selezionate i destinatari della vostra patch 253 238 ----------------------------------------------- 254 239 255 - Dovreste sempre inviare una copia della patch ai manutentori dei sottosistemi 256 - interessati dalle modifiche; date un'occhiata al file MAINTAINERS e alla storia 257 - delle revisioni per scoprire chi si occupa del codice. Lo script 258 - scripts/get_maintainer.pl può esservi d'aiuto (passategli il percorso alle 259 - vostre patch). Se non riuscite a trovare un manutentore per il sottosistema su 260 - cui state lavorando, allora Andrew Morton (akpm@linux-foundation.org) sarà la 261 - vostra ultima possibilità. 240 + Dovreste sempre inviare una copia della patch ai manutentori e alle liste di 241 + discussione dei sottosistemi interessati dalle modifiche; date un'occhiata al 242 + file MAINTAINERS e alla storia delle revisioni per scoprire chi si occupa del 243 + codice. Lo script scripts/get_maintainer.pl può esservi d'aiuto (passategli il 244 + percorso alle vostre patch). Se non riuscite a trovare un manutentore per il 245 + sottosistema su cui state lavorando, allora Andrew Morton 246 + (akpm@linux-foundation.org) sarà la vostra ultima possibilità. 247 + 248 + La lista linux-kernel@vger.kernel.org dovrebbe essere usata per l'invio di tutte 249 + le patch, ma il volume ha raggiunto un livello tale d'aver spinto alcuni 250 + sviluppatori a non seguirla più. Dunque, per favore, evitate di inviare messaggi 251 + scorrelati al tema della lista o a persone che non dovrebbero essere 252 + interessate all'argomento. 262 253 263 254 Normalmente, dovreste anche scegliere una lista di discussione a cui inviare la 264 255 vostra serie di patch. La lista di discussione linux-kernel@vger.kernel.org ··· 364 343 evidenziato. Quando inviate una versione successiva ricordatevi di aggiungere un 365 344 ``patch changelog`` alla email di intestazione o ad ogni singola patch spiegando 366 345 le differenze rispetto a sottomissioni precedenti (vedere 367 - :ref:`it_the_canonical_patch_format`). 346 + :ref:`it_the_canonical_patch_format`). Aggiungete a CC tutte le persone che 347 + vi hanno fornito dei commenti per notificarle di eventuali nuove versioni. 368 348 369 349 Leggete Documentation/translations/it_IT/process/email-clients.rst per 370 350 le raccomandazioni sui programmi di posta elettronica e l'etichetta da usare ··· 407 385 I revisori sono persone occupate e potrebbero non ricevere la vostra patch 408 386 immediatamente. 409 387 410 - Un tempo, le patch erano solite scomparire nel vuoto senza alcun commento, 411 - ma ora il processo di sviluppo funziona meglio. Dovreste ricevere commenti 412 - in una settimana o poco più; se questo non dovesse accadere, assicuratevi di 413 - aver inviato le patch correttamente. Aspettate almeno una settimana prima di 388 + Un tempo, le patch erano solite scomparire nel vuoto senza alcun commento, ma 389 + ora il processo di sviluppo funziona meglio. Dovreste ricevere commenti in poche 390 + settimane (tipicamente 2 o 3); se questo non dovesse accadere, assicuratevi di 391 + aver inviato le patch correttamente. Aspettate almeno una settimana prima di 414 392 rinviare le modifiche o sollecitare i revisori - probabilmente anche di più 415 393 durante la finestra d'integrazione. 416 394 ··· 574 552 Rammentate che se il baco è stato riportato in privato, dovrete chiedere il 575 553 permesso prima di poter utilizzare l'etichetta Reported-by. Questa etichetta va 576 554 usata per i bachi, dunque non usatela per richieste di nuove funzionalità. 555 + Questa etichetta dovrebbe essere seguita da quella Closes: con un indirizzo al 556 + rapporto, a meno che questo non sia disponibile sul web. L'etichetta Link: può 557 + essere usata in alternativa a Closes: se la patch corregge solo in parte il 558 + problema riportato nel rapporto. 577 559 578 560 L'etichetta Tested-by: indica che la patch è stata verificata con successo 579 561 (su un qualche sistema) dalla persona citata. Questa etichetta informa i ··· 833 807 è utile, potete usare https://lore.kernel.org/ per ottenere i collegamenti 834 808 ad una versione precedente di una serie di patch (per esempio, potete usarlo 835 809 per l'email introduttiva alla serie). 810 + 811 + Fornire informazioni circa i sorgenti 812 + ------------------------------------- 813 + 814 + Quando gli altri sviluppatori ricevono le vostre patch e iniziano il processo di 815 + revisione, è assolutamente necessario che sappiano qual è il commit/ramo di base 816 + su cui si base il vostro lavoro: considerate l'enorme quantità di sorgenti dei 817 + manutentori presenti al giorno d'oggi. Si noti ancora una volta la voce **T:** 818 + nel file MAINTAINERS spiegato sopra. 819 + 820 + Questo è ancora più importante per i processi automatizzati di CI che tentano di 821 + eseguire una serie di test per stabilire la qualità del codice prima che il 822 + manutentore inizi la revisione. 823 + 824 + Se si usa ``git format-patch`` per generare le patch, si possono includere 825 + automaticamente le informazioni sull'albero di base nell'invio usando il flag 826 + ``--base``. Il modo più semplice e comodo di usare questa opzione è con i rami 827 + topici:: 828 + 829 + $ git checkout -t -b my-topical-branch master 830 + Branch 'my-topical-branch' set up to track local branch 'master'. 831 + Switched to a new branch 'my-topical-branch' 832 + 833 + [perform your edits and commits] 834 + 835 + $ git format-patch --base=auto --cover-letter -o outgoing/ master 836 + outgoing/0000-cover-letter.patch 837 + outgoing/0001-First-Commit.patch 838 + outgoing/... 839 + 840 + Aprendo ``outgoing/0000-cover-letter.patch`` per la modifica, si noterà 841 + che ha ``base-commit:`` in fondo, questo fornisce al revisore e agli 842 + strumenti CI informazioni sufficienti per eseguire correttamente ``git am`` 843 + senza preoccuparsi dei conflitti:: 844 + 845 + $ git checkout -b patch-review [base-commit-id] 846 + Switched to a new branch 'patch-review' 847 + $ git am patches.mbox 848 + Applying: First Commit 849 + Applying: ... 850 + 851 + Consultate ``man git-format-patch`` per maggiori informazioni circa questa 852 + opzione. 853 + 854 + .. note:: 855 + 856 + L'opzione ``--base`` fu introdotta con git versione 2.9.0 857 + 858 + Se non si usa git per produrre le patch, si può comunque includere 859 + ``base-commit`` per indicare l'hash del commit dei sorgenti su cui si basa il 860 + lavoro. Dovreste aggiungerlo nella lettera di accompagnamento o nella prima 861 + patch della serie e dovrebbe essere collocato sotto la riga ``---`` o in fondo a 862 + tutti gli altri contenuti, subito prima della vostra firma e-mail. 863 + 864 + Assicuratevi che il commit si basi su sorgenti ufficiali del 865 + manutentore/mainline e non su sorgenti interni, accessibile solo a voi, 866 + altrimenti sarebbe inutile. 836 867 837 868 Riferimenti 838 869 -----------

+22 -2

Documentation/translations/it_IT/riscv/patch-acceptance.rst Documentation/translations/it_IT/arch/riscv/patch-acceptance.rst

··· 1 - .. include:: ../disclaimer-ita.rst 1 + .. include:: ../../disclaimer-ita.rst 2 2 3 - :Original: :doc:`../../../arch/riscv/patch-acceptance` 3 + :Original: :doc:`../../../../arch/riscv/patch-acceptance` 4 4 :Translator: Federico Vaga <federico.vaga@vaga.pv.it> 5 5 6 6 arch/riscv linee guida alla manutenzione per gli sviluppatori ··· 21 21 sperimentale. Desideriamo estendere questi stessi principi al codice 22 22 relativo all'architettura RISC-V che verrà accettato per l'inclusione 23 23 nel kernel. 24 + 25 + Patchwork 26 + --------- 27 + 28 + RISC-V ha un'istanza di patchwork dov'è possibile controllare lo stato delle patch: 29 + 30 + https://patchwork.kernel.org/project/linux-riscv/list/ 31 + 32 + Se la vostra patch non appare nella vista predefinita, i manutentori di RISC-V 33 + hanno probabilmente richiesto delle modifiche o si aspettano che venga applicata 34 + a un altro albero. 35 + 36 + Il processo automatico viene eseguito su questa istanza di patchwork, costruendo 37 + e collaudando le patch man mano che arrivano. Il processo applica le patch al 38 + riferimento HEAD corrente dei rami `for-next` e `fixes` dei sorgenti RISC-V, 39 + questo a seconda che la patch sia stata o meno individuata come correzione. In 40 + caso contrario, utilizzerà il ramo `master` di RISC-V. L'esatto commit a cui è 41 + stata applicata una serie di patch sarà annotato su patchwork. È improbabile che 42 + vengano applicate Le patch che non passano i controlli, nella maggior parte dei 43 + casi dovranno essere ripresentate. 24 44 25 45 In aggiunta alla lista delle verifiche da fare prima di inviare una patch 26 46 -------------------------------------------------------------------------

Configure Feed

Configure Feed