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. Consultate il seguente
145 Questa selezione di kernel di lungo periodo sono puramente dovuti ai loro
150 Il ciclo di vita di una patch
155 per assicurare che ogni patch sia di buona qualità e desiderata nel
157 meno importanti, o, nel caso di patch ampie e controverse, va avanti per anni.
158 Per uno sviluppatore la maggior frustrazione viene dalla mancanza di
159 comprensione di questo processo o dai tentativi di aggirarlo.
161 Nella speranza di ridurre questa frustrazione, questo documento spiegherà
169 della modifica - e come verranno soddisfatti. Il lavoro di progettazione
174 - Prima revisione. Le patch vengono pubblicate sulle liste di discussione
185 più estesa della patch e alla scoperta di problemi d'integrazione
205 - Rilascio stabile. Ora, il numero di utilizzatori che sono potenzialmente
209 - Manutenzione di lungo periodo. Nonostante sia possibile che uno sviluppatore
211 lascia una brutta impressione nella comunità di sviluppo. Integrare il
219 di lavoro) è quello di cercare di ridurre tutta la procedura ad una singola
221 a una condizione di frustrazione per tutti coloro che sono coinvolti.
227 del kernel: Linus Torvalds. Ma, per esempio, di tutte le 9500 patch
234 di utilizzare un sistema di "sottotenenti" basato sulla fiducia.
239 sviluppatore che ha piena responsabilità di tutto il codice presente in quel
240 sottosistema. Tali manutentori di sottosistema sono i guardiani
241 (in un certo senso) della parte di kernel che gestiscono; sono coloro che
245 I manutentori di sottosistema gestiscono ciascuno la propria parte dei sorgenti
248 di stilare una lista delle patch, includendo informazioni sull'autore ed
252 Quando la "finestra di integrazione" si apre, i manutentori di alto livello
253 chiederanno a Linus di "prendere" dai loro repositori le modifiche che hanno
254 selezionato per l'inclusione. Se Linus acconsente, il flusso di patch si
255 convoglierà nel repositorio di quest ultimo, divenendo così parte del ramo
257 singole patch ricevute durante l'operazione di integrazione varia.
259 generale, Linus confida nel fatto che i manutentori di sottosistema non
262 I manutentori di sottosistemi, a turno, possono "prendere" patch
265 dedicati ai driver per dispositivi di rete, rete senza fili, ecc. Tale
266 catena di repositori può essere più o meno lunga, benché raramente ecceda
269 catena si fida di coloro che gestiscono i livelli più bassi.
279 La catena di sottosistemi guida il flusso di patch all'interno del kernel,
281 patch pronte per la prossima finestra di integrazione?
283 che non ci siano altri conflitti di cui preoccuparsi; una modifica che, per
284 esempio, cambia il prototipo di una funzione fondamentale del kernel andrà in
285 conflitto con qualsiasi altra modifica che utilizzi la vecchia versione di
291 La risposta ci viene sotto forma di sorgenti -next, dove i sottosistemi sono
292 raccolti per essere testati e controllati. Il più vecchio di questi sorgenti,
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
299 state inviate in una lista di discussione, o possono essere applicate ad una
301 Di conseguenza, -mm opera come una specie di sottosistema "ultima spiaggia";
305 direttamente a Linus. In un tipico ciclo di sviluppo, circa il 5-10% delle
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;
326 tutte le patch incorporate durante una finestra di integrazione dovrebbero
328 della finestra di integrazione.
337 bisogno di maggior lavoro; una volta completato, possono essere spostate
338 all'interno del kernel nel posto più appropriato. Questo è il modo di tener
339 traccia dei driver che non sono ancora in linea con gli standard di codifica
348 accettati nel kernel, e indica anche la lista di persone da inserire in copia
353 driver all'interno del ramo principale, dove, con un po' di fortuna, saranno
355 di preparazione non è però la fine della storia, infatti, il codice che si
366 Come è possibile notare dal testo sopra, il processo di sviluppo del kernel
367 dipende pesantemente dalla capacità di guidare la raccolta di patch in
369 con l'uso di strumenti appropriati e potenti. Spiegare l'uso di tali
370 strumenti non è lo scopo di questo documento, ma c'è spazio per alcuni
373 In assoluto, nella comunità del kernel, predomina l'uso di git come sistema
374 di gestione dei sorgenti. Git è una delle diverse tipologie di sistemi
375 distribuiti di controllo versione che sono stati sviluppati nella comunità
378 vasto numero di patch. Git ha inoltre la reputazione di essere difficile
380 del kernel viene richiesta un po' di familiarità con git; anche se non lo
381 utilizzano per il proprio lavoro, hanno bisogno di git per tenersi al passo
404 Quilt è un sistema di gestione delle patch, piuttosto che un sistema
405 di gestione dei sorgenti. Non mantiene uno storico degli eventi; ma piuttosto
406 è orientato verso il tracciamento di uno specifico insieme di modifiche
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),
413 Liste di discussione
416 Una grossa parte del lavoro di sviluppo del Kernel Linux viene svolto tramite
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
424 Molte delle liste di discussione del Kernel girano su vger.kernel.org;
429 Esistono liste gestite altrove; un certo numero di queste sono in
432 La lista di discussione principale per lo sviluppo del kernel è, ovviamente,
434 raggiungere i 500 messaggi al giorno, la quantità di "rumore" è elevata,
436 sempre preoccupati di mostrare un alto livello di educazione. Ma non esiste
437 altro luogo dove la comunità di sviluppo del kernel si unisce per intero;
444 casella di posta principale. Così da essere in grado di ignorare il flusso
445 di mail per un certo periodo di tempo.
447 - Non cercate di seguire ogni conversazione - nessuno lo fa. È importante
449 conversazioni di lungo periodo possono deviare dall'argomento originario
452 - Non alimentate i troll. Se qualcuno cerca di creare nervosismo, ignoratelo.
455 tutti i Cc:. In assenza di importanti motivazioni (come una richiesta
458 usanza fa si che divenga inutile chiedere esplicitamente di essere inseriti
462 di far domande. Molti sviluppatori possono divenire impazienti con le
465 - Evitate il *top-posting* (cioè la pratica di mettere la vostra risposta sopra
469 - Chiedete nella lista di discussione corretta. Linux-kernel può essere un
470 punto di incontro generale, ma non è il miglior posto dove trovare
473 Infine, la ricerca della corretta lista di discussione è uno degli errori più
476 di chiedere sulla lista netdev, che è la lista frequentata dagli sviluppatori
477 di rete. Ci sono poi altre liste per i sottosistemi SCSI, video4linux, IDE,
478 filesystem, etc. Il miglior posto dove cercare una lista di discussione è il
486 rendono l'inizio di tale relazione più difficile di quello che dovrebbe essere.
488 Le aziende spesso cercano di assumere sviluppatori noti per creare un gruppo
489 di sviluppo iniziale. Questo, in effetti, può essere una tecnica efficace.
490 Ma risulta anche essere dispendiosa e non va ad accrescere il bacino di
493 all'investimento un po' di tempo. Prendersi questo tempo può fornire
494 al datore di lavoro un gruppo di sviluppatori che comprendono sia il kernel
495 che l'azienda stessa, e che possono supportare la formazione di altre persone.
499 di partenza. Iniziare con un grande progetto può rivelarsi intimidatorio;
500 spesso all'inizio si vuole solo verificare il terreno con qualcosa di piccolo.
502 creazione di patch che vanno a sistemare errori di battitura o
504 patch creano un certo livello di rumore che distrae l'intera comunità di
505 sviluppo, quindi, sempre di più, esse vengono degradate. I nuovi sviluppatori
514 sicuramente quello di "assicurarsi che il kernel funzioni alla
516 la vostra mano". Solitamente il modo per fare ciò è quello di
522 In assenza di problemi ovvi da risolvere, si consiglia agli sviluppatori
523 di consultare, in generale, la lista di regressioni e di bachi aperti.
524 Non c'è mai carenza di problematiche bisognose di essere sistemate;
527 all'interno della comunità di sviluppo.