Lines Matching +full:non +full:- +full:standard
1 .. include:: ../disclaimer-ita.rst
14 sviluppo kernel Linux. Il documento non tratterà alcun aspetto
23 ------------
36 L'assembly (di qualsiasi architettura) non è richiesto, a meno che non
38 Sebbene essi non siano un buon sostituto ad un solido studio del
39 linguaggio C o ad anni di esperienza, i seguenti libri sono, se non
42 - "The C Programming Language" di Kernighan e Ritchie [Prentice Hall]
43 - "Practical C Programming" di Steve Oualline [O'Reilly]
44 - "C: A Reference Manual" di Harbison and Steele [Prentice Hall]
47 Sebbene si attenga allo standard ISO C11, esso utilizza una serie di
48 estensioni che non sono previste in questo standard. Il kernel è un
49 ambiente C indipendente, che non ha alcuna dipendenza dalle librerie
50 C standard, così alcune parti del C standard non sono supportate.
51 Le divisioni ``long long`` e numeri in virgola mobile non sono permessi.
53 riguardo gli strumenti e le estensioni in uso, e sfortunatamente non
59 standard di codifica, di stile e di procedura. Questi standard sono stati
62 imparare, in anticipo, il più possibile circa questi standard, poichè ben
63 spiegati; non aspettatevi che gli altri si adattino al vostro modo di fare
67 ------------
71 sulla licenza, contattate un avvocato, non chiedete sulle liste di discussione
72 del kernel Linux. Le persone presenti in queste liste non sono avvocati,
73 e non dovreste basarvi sulle loro dichiarazioni in materia giuridica.
77 https://www.gnu.org/licenses/gpl-faq.html
80 --------------
89 lista linux-[email protected].
94 :ref:`Documentation/translations/it_IT/admin-guide/README.rst <it_readme>`
104 :ref:`Documentation/translations/it_IT/process/coding-style.rst <it_codingstyle>`
112 :ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`
115 con successo, includendo (ma non solo questo):
117 - Contenuto delle email
118 - Formato delle email
119 - I destinatari delle email
121 Seguire tali regole non garantirà il successo (tutte le patch sono soggette
122 a controlli realitivi a contenuto e stile), ma non seguirle lo precluderà
131 https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html
133 :ref:`Documentation/translations/it_IT/process/stable-api-nonsense.rst <it_stable_api_nonsense>`
136 non avere un API stabile all'interno del kernel, incluso cose come:
138 - Sottosistemi shim-layers (per compatibilità?)
139 - Portabilità fra Sistemi Operativi dei driver.
140 - Attenuare i rapidi cambiamenti all'interno dei sorgenti del kernel
147 :ref:`Documentation/translations/it_IT/process/security-bugs.rst <it_securitybugs>`
152 :ref:`Documentation/translations/it_IT/process/management-style.rst <it_managementstyle>`
160 :ref:`Documentation/translations/it_IT/process/stable-kernel-rules.rst <it_stable_kernel_rules>`
165 :ref:`Documentation/translations/it_IT/process/kernel-docs.rst <it_kernel_docs>`
167 Per favore consultate questa lista se non trovate ciò che cercate nella
170 :ref:`Documentation/translations/it_IT/process/applying-patches.rst <it_applying_patches>`
196 -------------------------------------
197 Se non sapete nulla sullo sviluppo del kernel Linux, dovreste dare uno
214 Se non sapete dove cominciare, ma volete cercare delle attività dalle quali
225 successivo da svolgere, se non ne avrete ancora idea.
228 è imperativo comprendere come tale codice funziona. A questo scopo, non c'è
232 il progetto Linux Cross-Reference, che è in grado di presentare codice
240 -----------------------
244 - I sorgenti kernel 4.x
245 - I sorgenti stabili del kernel 4.x.y -stable
246 - Sorgenti dei sottosistemi del kernel e le loro modifiche
247 - Il kernel 4.x -next per test d'integrazione
256 - Non appena un nuovo kernel viene rilasciato si apre una finestra di due
259 inseriti nel ramo -next del kernel per alcune settimane. Il modo migliore
262 https://git-scm.com/) ma anche delle patch vanno bene.
264 - Al termine delle due settimane un kernel -rc1 viene rilasciato e
267 regressione. I bachi che sono sempre esistiti non sono considerabili come
270 accettato dopo la -rc1 poiché non esistono rischi di una possibile
272 auto-contenuto e non influisce su aree esterne al codice che è stato
274 la -rc1 è stata rilasciata, ma è anche necessario inviare le patch ad
277 - Una nuova -rc viene rilasciata ogni volta che Linus reputa che gli attuali
279 L'obiettivo è quello di rilasciare una nuova -rc ogni settimana.
281 - Il processo continua fino a che il kernel è considerato "pronto"; tale
285 kernel-linux in merito ai rilasci del kernel:
288 legato allo stato dei bachi e non ad una cronologia preventiva."*
290 I sorgenti stabili del kernel 4.x.y -stable
293 I kernel con versioni in 3-parti sono "kernel stabili". Essi contengono
298 e stabile e non sono interessati a dare il proprio contributo alla verifica
301 Se non è disponibile alcun kernel 4.x.y., quello più aggiornato e stabile
306 approssimativamente di due settimane, ma può essere più lungo se non si
310 Il file Documentation/process/stable-kernel-rules.rst (nei sorgenti) documenta
311 quali tipologie di modifiche sono accettate per i sorgenti -stable, e come
318 I manutentori dei diversi sottosistemi del kernel --- ed anche molti
319 sviluppatori di sottosistemi --- mostrano il loro attuale stato di sviluppo
339 Il kernel 4.x -next per test d'integrazione
347 https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
349 In questo modo, i kernel -next offrono uno sguardo riassuntivo su quello che
352 Coloro che vorranno fare dei test d'esecuzione del kernel -next sono più che
357 -------------
359 Il file 'Documentation/admin-guide/reporting-issues.rst' nella
365 --------------------------
368 quello di riparare bachi riportati da altre persone. Non solo aiuterete a far
372 acquisire meriti tra gli altri sviluppatori, perchè non a molte persone piace
385 --------------------
397 https://lore.kernel.org/linux-kernel/
419 conoscenza) potrebbe diventare abbastanza lunga. Non cancellate nessuno dalla
420 lista di CC: senza un buon motivo, e non rispondete solo all'indirizzo
422 ricevere la stessa email due volte: una dal mittente ed una dalla lista; e non
423 cercate di modificarla aggiungendo intestazioni stravaganti, agli altri non
429 blocchi citati, non scrivete all'inizio dell'email.
432 leggibili come indicato in Documentation/process/submitting-patches.rst.
433 Gli sviluppatori kernel non vogliono avere a che fare con allegati o patch
436 Assicuratevi di utilizzare un gestore di mail che non alterì gli spazi ed i
438 cercare di sottoporre la vostra stessa patch. Se non funziona, sistemate il
439 vostro programma di posta, o cambiatelo, finché non funziona.
445 ------------------------
451 - critiche
452 - commenti
453 - richieste di cambiamento
454 - richieste di spiegazioni
455 - nulla
461 modifiche suggerite non dovrebbero essere fatte.
462 Se non riceverete risposte, aspettate qualche giorno e riprovate ancora,
465 Cosa non dovreste fare?
467 - aspettarvi che la vostra modifica venga accettata senza problemi
468 - mettervi sulla difensiva
469 - ignorare i commenti
470 - sottomettere nuovamente la modifica senza fare nessuno dei cambiamenti
482 Questo **non** implica che la vostra patch non sarà accettata, e questo
483 **non** è contro di voi personalmente.
488 --------------------------------------------------------------
496 - "Questo risolve più problematiche."
497 - "Questo elimina 2000 stringhe di codice."
498 - "Qui una modifica che spiega cosa sto cercando di fare."
499 - "L'ho testato su 5 diverse architetture.."
500 - "Qui una serie di piccole modifiche che.."
501 - "Questo aumenta le prestazioni di macchine standard..."
505 - "Lo abbiamo fatto in questo modo in AIX/ptx/Solaris, di conseguenza
507 - "Ho fatto questo per 20 anni, quindi.."
508 - "Questo è richiesto dalla mia Azienda per far soldi"
509 - "Questo è per la linea di prodotti della nostra Azienda"
510 - "Ecco il mio documento di design di 1000 pagine che descrive ciò che ho
512 - "Ci ho lavorato per 6 mesi..."
513 - "Ecco una patch da 5000 righe che.."
514 - "Ho riscritto il pasticcio attuale, ed ecco qua.."
515 - "Ho una scadenza, e questa modifica ha bisogno di essere approvata ora"
523 livellare il terreno di gioco perchè non è possibile indovinare il genere
529 La lingua potrebbe essere un ostacolo per quelle persone che non si trovano
537 ----------------------------
539 La comunità del kernel Linux non accetta con piacere grossi pezzi di codice
546 senta che state lavorando con loro, e che non li stiate sfruttando come
547 discarica per le vostre aggiunte. In ogni caso, non inviate 50 email nello
562 non va. È molto più facile annullare le modifiche una per una che
566 2) È importante non solo inviare piccole modifiche, ma anche riscriverle e
572 di uno studente (di matematica). L'insegnante non vuole vedere le
575 possibile. Un buono studente lo sa, e non presenterebbe mai le
579 revisori non vogliono vedere il procedimento che sta dietro al
588 la vostra intera attività non lo sia ancora.
590 In fine, rendetevi conto che non è accettabile inviare delle modifiche
595 --------------------------------
603 -------------------------------
610 - perchè la modifica è necessaria
611 - l'approccio d'insieme alla patch
612 - dettagli supplementari
613 - risultati dei test
623 miglioramento che richiede molta pazienza e determinazione. Ma non mollate,
630 ----------
634 Randy Dunlap e Gerrit Huizenga per la lista di cose che dovreste e non
640 non sarebbe stato possibile.
642 Manutentore: Greg Kroah-Hartman <[email protected]>