Lines Matching refs:di
8 Come funziona il processo di sviluppo
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
15 lo sviluppo più agevole. È richiesta una solida conoscenza di come tale
21 Gli sviluppatori kernel utilizzano un calendario di rilascio generico, dove
36 rilascio contiene quasi 13,000 gruppi di modifiche con ulteriori
37 modifiche a parecchie migliaia di linee di codice. La 5.x. è pertanto la
38 linea di confine nello sviluppo del kernel Linux; il kernel utilizza un sistema
39 di sviluppo continuo che integra costantemente nuove importanti modifiche.
42 patch di ogni rilascio. All'inizio di ogni ciclo di sviluppo, la
43 "finestra di inclusione" viene dichiarata aperta. In quel momento il codice
44 ritenuto sufficientemente stabile(e che è accettato dalla comunità di sviluppo)
46 patch per un nuovo ciclo di sviluppo (e tutte le più importanti modifiche)
48 1000 modifiche ("patch" o "gruppo di modifiche") al giorno.
51 "finestra di inclusione" non escono dal nulla; questi infatti, sono stati
52 raccolti e, verificati in anticipo. Il funzionamento di tale procedimento
55 La finestra di inclusione resta attiva approssimativamente per due settimane.
56 Al termine di questo periodo, Linus Torvald dichiarerà che la finestra è
60 Questo rilascio indica che il momento di aggiungere nuovi componenti è
61 passato, e che è iniziato il periodo di stabilizzazione del prossimo kernel.
66 Gli sviluppatori che tenteranno di aggiungere nuovi elementi al di fuori della
67 finestra di inclusione, tendenzialmente, riceveranno un accoglienza poco
68 amichevole. Come regola generale: se vi perdete la finestra di inclusione per
69 un dato componente, la cosa migliore da fare è aspettare il ciclo di sviluppo
71 supportati in precedenza; se toccano codice non facente parte di quello
81 Esempio: ecco com'è andato il ciclo di sviluppo della versione 5.4
87 30 settembre 5.4-rc1, finestra di inclusione chiusa
98 In che modo gli sviluppatori decidono quando chiudere il ciclo di sviluppo e
99 creare quindi una rilascio stabile? Un metro valido è il numero di regressioni
104 durante il periodo di stabilizzazione.
106 L'obiettivo degli sviluppatori è quello di aggiustare tutte le regressioni
108 tipo di perfezione difficilmente viene raggiunta; esistono troppe variabili
109 in un progetto di questa portata. Arriva un punto dove ritardare il rilascio
110 finale peggiora la situazione; la quantità di modifiche in attesa della
111 prossima finestra di inclusione crescerà enormemente, creando ancor più
113 manciata di regressioni delle quali, si spera, nessuna è grave.
122 iniziale, i kernel ricevono aggiornamenti per più di un ciclo di sviluppo.
139 riceveranno assistenza per un lungo periodo di tempo. Al momento in cui
152 Questa selezione di kernel di lungo periodo sono puramente dovuti ai loro
157 Il ciclo di vita di una patch
162 per assicurare che ogni patch sia di buona qualità e desiderata nel
164 meno importanti, o, nel caso di patch ampie e controverse, va avanti per anni.
165 Per uno sviluppatore la maggior frustrazione viene dalla mancanza di
166 comprensione di questo processo o dai tentativi di aggirarlo.
168 Nella speranza di ridurre questa frustrazione, questo documento spiegherà
176 della modifica - e come verranno soddisfatti. Il lavoro di progettazione
181 - Prima revisione. Le patch vengono pubblicate sulle liste di discussione
192 più estesa della patch e alla scoperta di problemi d'integrazione
212 - Rilascio stabile. Ora, il numero di utilizzatori che sono potenzialmente
216 - Manutenzione di lungo periodo. Nonostante sia possibile che uno sviluppatore
218 lascia una brutta impressione nella comunità di sviluppo. Integrare il
226 di lavoro) è quello di cercare di ridurre tutta la procedura ad una singola
228 a una condizione di frustrazione per tutti coloro che sono coinvolti.
234 del kernel: Linus Torvalds. Ma, per esempio, di tutte le 9500 patch
241 di utilizzare un sistema di "sottotenenti" basato sulla fiducia.
246 sviluppatore che ha piena responsabilità di tutto il codice presente in quel
247 sottosistema. Tali manutentori di sottosistema sono i guardiani
248 (in un certo senso) della parte di kernel che gestiscono; sono coloro che
252 I manutentori di sottosistema gestiscono ciascuno la propria parte dei sorgenti
255 di stilare una lista delle patch, includendo informazioni sull'autore ed
259 Quando la "finestra di integrazione" si apre, i manutentori di alto livello
260 chiederanno a Linus di "prendere" dai loro repositori le modifiche che hanno
261 selezionato per l'inclusione. Se Linus acconsente, il flusso di patch si
262 convoglierà nel repositorio di quest ultimo, divenendo così parte del ramo
264 singole patch ricevute durante l'operazione di integrazione varia.
266 generale, Linus confida nel fatto che i manutentori di sottosistema non
269 I manutentori di sottosistemi, a turno, possono "prendere" patch
272 dedicati ai driver per dispositivi di rete, rete senza fili, ecc. Tale
273 catena di repositori può essere più o meno lunga, benché raramente ecceda
276 catena si fida di coloro che gestiscono i livelli più bassi.
286 La catena di sottosistemi guida il flusso di patch all'interno del kernel,
288 patch pronte per la prossima finestra di integrazione?
290 che non ci siano altri conflitti di cui preoccuparsi; una modifica che, per
291 esempio, cambia il prototipo di una funzione fondamentale del kernel andrà in
292 conflitto con qualsiasi altra modifica che utilizzi la vecchia versione di
298 La risposta ci viene sotto forma di sorgenti -next, dove i sottosistemi sono
299 raccolti per essere testati e controllati. Il più vecchio di questi sorgenti,
301 di tutto). L'-mm integra patch proveniente da una lunga lista di sottosistemi;
304 Oltre a questo, -mm contiene una raccolta significativa di patch che sono
306 state inviate in una lista di discussione, o possono essere applicate ad una
308 Di conseguenza, -mm opera come una specie di sottosistema "ultima spiaggia";
312 direttamente a Linus. In un tipico ciclo di sviluppo, circa il 5-10% delle
325 definizione, un'istantanea di come dovrà apparire il ramo principale dopo che
326 la prossima finestra di inclusione si chiuderà. I linux-next sono annunciati
327 sulla lista di discussione linux-kernel e linux-next nel momento in cui
332 Linux-next è divenuto parte integrante del processo di sviluppo del kernel;
333 tutte le patch incorporate durante una finestra di integrazione dovrebbero
335 della finestra di integrazione.
344 bisogno di maggior lavoro; una volta completato, possono essere spostate
345 all'interno del kernel nel posto più appropriato. Questo è il modo di tener
346 traccia dei driver che non sono ancora in linea con gli standard di codifica
355 accettati nel kernel, e indica anche la lista di persone da inserire in copia
360 driver all'interno del ramo principale, dove, con un po' di fortuna, saranno
362 di preparazione non è però la fine della storia, infatti, il codice che si
373 Come è possibile notare dal testo sopra, il processo di sviluppo del kernel
374 dipende pesantemente dalla capacità di guidare la raccolta di patch in
376 con l'uso di strumenti appropriati e potenti. Spiegare l'uso di tali
377 strumenti non è lo scopo di questo documento, ma c'è spazio per alcuni
380 In assoluto, nella comunità del kernel, predomina l'uso di git come sistema
381 di gestione dei sorgenti. Git è una delle diverse tipologie di sistemi
382 distribuiti di controllo versione che sono stati sviluppati nella comunità
385 vasto numero di patch. Git ha inoltre la reputazione di essere difficile
387 del kernel viene richiesta un po' di familiarità con git; anche se non lo
388 utilizzano per il proprio lavoro, hanno bisogno di git per tenersi al passo
411 Quilt è un sistema di gestione delle patch, piuttosto che un sistema
412 di gestione dei sorgenti. Non mantiene uno storico degli eventi; ma piuttosto
413 è orientato verso il tracciamento di uno specifico insieme di modifiche
414 rispetto ad un codice in evoluzione. Molti dei più grandi manutentori di
416 integrate. Per la gestione di certe tipologie di sorgenti (-mm, per esempio),
420 Liste di discussione
423 Una grossa parte del lavoro di sviluppo del Kernel Linux viene svolto tramite
424 le liste di discussione. È difficile essere un membro della comunità
426 parte. Ma, le liste di discussione di Linux rappresentano un potenziale
427 problema per gli sviluppatori, che rischiano di venir sepolti da un mare di
431 Molte delle liste di discussione del Kernel girano su vger.kernel.org;
436 Esistono liste gestite altrove; un certo numero di queste sono in
439 La lista di discussione principale per lo sviluppo del kernel è, ovviamente,
441 raggiungere i 500 messaggi al giorno, la quantità di "rumore" è elevata,
443 sempre preoccupati di mostrare un alto livello di educazione. Ma non esiste
444 altro luogo dove la comunità di sviluppo del kernel si unisce per intero;
451 casella di posta principale. Così da essere in grado di ignorare il flusso
452 di mail per un certo periodo di tempo.
454 - Non cercate di seguire ogni conversazione - nessuno lo fa. È importante
456 conversazioni di lungo periodo possono deviare dall'argomento originario
459 - Non alimentate i troll. Se qualcuno cerca di creare nervosismo, ignoratelo.
462 tutti i Cc:. In assenza di importanti motivazioni (come una richiesta
465 usanza fa si che divenga inutile chiedere esplicitamente di essere inseriti
469 di far domande. Molti sviluppatori possono divenire impazienti con le
472 - Evitate il *top-posting* (cioè la pratica di mettere la vostra risposta sopra
476 - Chiedete nella lista di discussione corretta. Linux-kernel può essere un
477 punto di incontro generale, ma non è il miglior posto dove trovare
480 Infine, la ricerca della corretta lista di discussione è uno degli errori più
483 di chiedere sulla lista netdev, che è la lista frequentata dagli sviluppatori
484 di rete. Ci sono poi altre liste per i sottosistemi SCSI, video4linux, IDE,
485 filesystem, etc. Il miglior posto dove cercare una lista di discussione è il
493 rendono l'inizio di tale relazione più difficile di quello che dovrebbe essere.
495 Le aziende spesso cercano di assumere sviluppatori noti per creare un gruppo
496 di sviluppo iniziale. Questo, in effetti, può essere una tecnica efficace.
497 Ma risulta anche essere dispendiosa e non va ad accrescere il bacino di
500 all'investimento un po' di tempo. Prendersi questo tempo può fornire
501 al datore di lavoro un gruppo di sviluppatori che comprendono sia il kernel
502 che l'azienda stessa, e che possono supportare la formazione di altre persone.
506 di partenza. Iniziare con un grande progetto può rivelarsi intimidatorio;
507 spesso all'inizio si vuole solo verificare il terreno con qualcosa di piccolo.
509 creazione di patch che vanno a sistemare errori di battitura o
511 patch creano un certo livello di rumore che distrae l'intera comunità di
512 sviluppo, quindi, sempre di più, esse vengono degradate. I nuovi sviluppatori
521 sicuramente quello di "assicurarsi che il kernel funzioni alla
523 la vostra mano". Solitamente il modo per fare ciò è quello di
529 In assenza di problemi ovvi da risolvere, si consiglia agli sviluppatori
530 di consultare, in generale, la lista di regressioni e di bachi aperti.
531 Non c'è mai carenza di problematiche bisognose di essere sistemate;
534 all'interno della comunità di sviluppo.