Lines Matching +full:un +full:-
1 .. include:: ../disclaimer-ita.rst
12 un numero di utenti e sviluppatori relativamente basso. Con una base
13 di milioni di utenti e con 2000 sviluppatori coinvolti nel giro di un anno,
14 il kernel da allora ha messo in atto un certo numero di procedure per rendere
19 -------------------
21 Gli sviluppatori kernel utilizzano un calendario di rilascio generico, dove
22 ogni due o tre mesi viene effettuata un rilascio importante del kernel.
34 Ciascun rilascio 5.x è un importante rilascio del kernel con nuove
35 funzionalità, modifiche interne dell'API, e molto altro. Un tipico
38 linea di confine nello sviluppo del kernel Linux; il kernel utilizza un sistema
46 patch per un nuovo ciclo di sviluppo (e tutte le più importanti modifiche)
47 saranno inserite durante questo periodo, ad un ritmo che si attesta sulle
59 che emerge al termine della finestra d'inclusione si chiamerà 5.6-rc1.
67 finestra di inclusione, tendenzialmente, riceveranno un accoglienza poco
69 un dato componente, la cosa migliore da fare è aspettare il ciclo di sviluppo
70 successivo (un'eccezione può essere fatta per i driver per hardware non
73 sicurezza in un qualsiasi momento)
76 il ritmo delle modifiche rallenta col tempo. Linus rilascia un nuovo
77 kernel -rc circa una volta alla settimana; e ne usciranno circa 6 o 9 prima
87 30 settembre 5.4-rc1, finestra di inclusione chiusa
88 6 ottobre 5.4-rc2
89 13 ottobre 5.4-rc3
90 20 ottobre 5.4-rc4
91 27 ottobre 5.4-rc5
92 3 novembre 5.4-rc6
93 10 novembre 5.4-rc7
94 17 novembre 5.4-rc8
99 creare quindi una rilascio stabile? Un metro valido è il numero di regressioni
109 in un progetto di questa portata. Arriva un punto dove ritardare il rilascio
115 Una volta che un rilascio stabile è fatto, il suo costante mantenimento è
116 affidato al "squadra stabilità", attualmente composta da Greg Kroah-Hartman.
119 considerazione per un rilascio d'aggiornamento, una modifica deve:
120 (1) correggere un baco importante (2) essere già inserita nel ramo principale
122 iniziale, i kernel ricevono aggiornamenti per più di un ciclo di sviluppo.
139 riceveranno assistenza per un lungo periodo di tempo. Consultate il seguente
151 -----------------------------
162 come una patch viene inserita nel kernel. Ciò che segue è un'introduzione
168 - Progetto. In questa fase sono stabilite quelli che sono i requisiti
169 della modifica - e come verranno soddisfatti. Il lavoro di progettazione
174 - Prima revisione. Le patch vengono pubblicate sulle liste di discussione
179 - Revisione più ampia. Quando la patch è quasi pronta per essere inserita
180 nel ramo principale, un manutentore importante del sottosistema dovrebbe
181 accettarla - anche se, questa accettazione non è una garanzia che la
183 del sottosistema in questione e nei sorgenti -next (descritti sotto).
188 - Per favore, tenete da conto che la maggior parte dei manutentori ha
189 anche un lavoro quotidiano, quindi integrare le vostre patch potrebbe
199 - Inclusione nel ramo principale. Eventualmente, una buona patch verrà
205 - Rilascio stabile. Ora, il numero di utilizzatori che sono potenzialmente
209 - Manutenzione di lungo periodo. Nonostante sia possibile che uno sviluppatore
224 --------------------------------------
231 un singolo sviluppatore non può controllare e selezionare
234 di utilizzare un sistema di "sottotenenti" basato sulla fiducia.
238 strumenti, etc. Molti sottosistemi hanno un manutentore designato: ovvero uno
241 (in un certo senso) della parte di kernel che gestiscono; sono coloro che
271 Chiaramente, in un sistema come questo, l'inserimento delle patch all'interno
276 Sorgenti -next
277 --------------
280 ma solleva anche un interessante quesito: se qualcuno volesse vedere tutte le
289 d'interesse, ma questo sarebbe un lavoro enorme e fallace.
291 La risposta ci viene sotto forma di sorgenti -next, dove i sottosistemi sono
293 gestito da Andrew Morton, è chiamato "-mm" (memory management, che è l'inizio
294 di tutto). L'-mm integra patch proveniente da una lunga lista di sottosistemi;
297 Oltre a questo, -mm contiene una raccolta significativa di patch che sono
300 parte del kernel per la quale non esiste un sottosistema dedicato.
301 Di conseguenza, -mm opera come una specie di sottosistema "ultima spiaggia";
303 allora è probabile che finirà in -mm. Le patch passate per -mm
305 direttamente a Linus. In un tipico ciclo di sviluppo, circa il 5-10% delle
306 patch andrà nel ramo principale attraverso -mm.
308 La patch -mm correnti sono disponibili nella cartella "mmotm" (-mm of
313 È molto probabile che l'uso dei sorgenti MMOTM diventi un'esperienza
317 è linux-next, gestito da Stephen Rothwell. I sorgenti linux-next sono, per
318 definizione, un'istantanea di come dovrà apparire il ramo principale dopo che
319 la prossima finestra di inclusione si chiuderà. I linux-next sono annunciati
320 sulla lista di discussione linux-kernel e linux-next nel momento in cui
325 Linux-next è divenuto parte integrante del processo di sviluppo del kernel;
327 aver trovato la propria strada in linux-next, a volte anche prima dell'apertura
332 ------------------------
335 molte sotto-cartelle per i driver o i filesystem che stanno per essere aggiunti
343 Greg Kroah-Hartman attualmente gestisce i sorgenti in preparazione. I driver
345 la propria sotto-cartella in drivers/staging/. Assieme ai file sorgenti
346 dei driver, dovrebbe essere presente nella stessa cartella anche un file TODO.
353 driver all'interno del ramo principale, dove, con un po' di fortuna, saranno
359 nel migliore dei casi, una tappa sulla strada verso il divenire un driver
364 ---------
377 comporta abbastanza bene quando ha a che fare con repositori grandi e con un
380 del kernel viene richiesta un po' di familiarità con git; anche se non lo
387 http://git-scm.com/
389 Qui troverete i riferimenti alla documentazione e alle guide passo-passo.
397 un'interfaccia che potrebbe risultare più semplice da utilizzare.
404 Quilt è un sistema di gestione delle patch, piuttosto che un sistema
407 rispetto ad un codice in evoluzione. Molti dei più grandi manutentori di
409 integrate. Per la gestione di certe tipologie di sorgenti (-mm, per esempio),
414 --------------------
417 le liste di discussione. È difficile essere un membro della comunità
419 parte. Ma, le liste di discussione di Linux rappresentano un potenziale
420 problema per gli sviluppatori, che rischiano di venir sepolti da un mare di
427 http://vger.kernel.org/vger-lists.html
429 Esistono liste gestite altrove; un certo numero di queste sono in
433 linux-kernel. Questa lista è un luogo ostile dove trovarsi; i volumi possono
436 sempre preoccupati di mostrare un alto livello di educazione. Ma non esiste
441 linux-kernel:
443 - Tenete la lista in una cartella separata, piuttosto che inserirla nella
445 di mail per un certo periodo di tempo.
447 - Non cercate di seguire ogni conversazione - nessuno lo fa. È importante
452 - Non alimentate i troll. Se qualcuno cerca di creare nervosismo, ignoratelo.
454 - Quando rispondete ad una mail linux-kernel (o ad altre liste) mantenete
461 - Cercate nell'archivio della lista (e nella rete nella sua totalità) prima
465 - Rispondete sotto alla porzione di righe citate, così da dare un contesto alle
468 leggete :ref:`Documentation/translations/it_IT/process/submitting-patches.rst
472 - Chiedete nella lista di discussione corretta. Linux-kernel può essere un
478 relativa alla rete su linux-kernel riceverà quasi certamente il suggerimento
485 -----------------------------------
487 Sono comuni le domande sul come iniziare con lo sviluppo del kernel - sia da
491 Le aziende spesso cercano di assumere sviluppatori noti per creare un gruppo
496 all'investimento un po' di tempo. Prendersi questo tempo può fornire
497 al datore di lavoro un gruppo di sviluppatori che comprendono sia il kernel
502 di partenza. Iniziare con un grande progetto può rivelarsi intimidatorio;
507 patch creano un certo livello di rumore che distrae l'intera comunità di
516 Il primo progetto per un neofita del kernel dovrebbe essere
521 persistenza!) ma va bene - è parte dello sviluppo kernel.