2018-11-08 16:24:15 -07:00
|
|
|
.. include:: ../disclaimer-ita.rst
|
|
|
|
|
|
|
|
:Original: :ref:`Documentation/process/2.Process.rst <development_process>`
|
2018-12-02 10:40:10 -07:00
|
|
|
:Translator: Alessia Mantegazza <amantegazza@vaga.pv.it>
|
2018-11-08 16:24:15 -07:00
|
|
|
|
|
|
|
.. _it_development_process:
|
|
|
|
|
|
|
|
Come funziona il processo di sviluppo
|
|
|
|
=====================================
|
|
|
|
|
2018-12-02 10:40:10 -07:00
|
|
|
Lo sviluppo del Kernel agli inizi degli anno '90 era abbastanza libero, con
|
|
|
|
un numero di utenti e sviluppatori relativamente basso. Con una base
|
|
|
|
di milioni di utenti e con 2000 sviluppatori coinvolti nel giro di un anno,
|
|
|
|
il kernel da allora ha messo in atto un certo numero di procedure per rendere
|
|
|
|
lo sviluppo più agevole. È richiesta una solida conoscenza di come tale
|
|
|
|
processo si svolge per poter esserne parte attiva.
|
2018-11-08 16:24:15 -07:00
|
|
|
|
2018-12-02 10:40:10 -07:00
|
|
|
Il quadro d'insieme
|
|
|
|
-------------------
|
|
|
|
|
|
|
|
Gli sviluppatori kernel utilizzano un calendario di rilascio generico, dove
|
|
|
|
ogni due o tre mesi viene effettuata un rilascio importante del kernel.
|
|
|
|
I rilasci più recenti sono stati:
|
|
|
|
|
|
|
|
====== =================
|
2020-04-30 15:20:37 -07:00
|
|
|
5.0 3 marzo, 2019
|
|
|
|
5.1 5 maggio, 2019
|
|
|
|
5.2 7 luglio, 2019
|
|
|
|
5.3 15 settembre, 2019
|
|
|
|
5.4 24 novembre, 2019
|
|
|
|
5.5 6 gennaio, 2020
|
2018-12-02 10:40:10 -07:00
|
|
|
====== =================
|
|
|
|
|
2020-04-30 15:20:37 -07:00
|
|
|
Ciascun rilascio 5.x è un importante rilascio del kernel con nuove
|
2018-12-02 10:40:10 -07:00
|
|
|
funzionalità, modifiche interne dell'API, e molto altro. Un tipico
|
2020-04-30 15:20:37 -07:00
|
|
|
rilascio contiene quasi 13,000 gruppi di modifiche con ulteriori
|
|
|
|
modifiche a parecchie migliaia di linee di codice. La 5.x. è pertanto la
|
2018-12-02 10:40:10 -07:00
|
|
|
linea di confine nello sviluppo del kernel Linux; il kernel utilizza un sistema
|
|
|
|
di sviluppo continuo che integra costantemente nuove importanti modifiche.
|
|
|
|
|
|
|
|
Viene seguita una disciplina abbastanza lineare per l'inclusione delle
|
|
|
|
patch di ogni rilascio. All'inizio di ogni ciclo di sviluppo, la
|
|
|
|
"finestra di inclusione" viene dichiarata aperta. In quel momento il codice
|
|
|
|
ritenuto sufficientemente stabile(e che è accettato dalla comunità di sviluppo)
|
|
|
|
viene incluso nel ramo principale del kernel. La maggior parte delle
|
|
|
|
patch per un nuovo ciclo di sviluppo (e tutte le più importanti modifiche)
|
|
|
|
saranno inserite durante questo periodo, ad un ritmo che si attesta sulle
|
|
|
|
1000 modifiche ("patch" o "gruppo di modifiche") al giorno.
|
|
|
|
|
|
|
|
(per inciso, vale la pena notare che i cambiamenti integrati durante la
|
|
|
|
"finestra di inclusione" non escono dal nulla; questi infatti, sono stati
|
|
|
|
raccolti e, verificati in anticipo. Il funzionamento di tale procedimento
|
|
|
|
verrà descritto dettagliatamente più avanti).
|
|
|
|
|
|
|
|
La finestra di inclusione resta attiva approssimativamente per due settimane.
|
|
|
|
Al termine di questo periodo, Linus Torvald dichiarerà che la finestra è
|
|
|
|
chiusa e rilascerà il primo degli "rc" del kernel.
|
2020-04-30 15:20:37 -07:00
|
|
|
Per il kernel che è destinato ad essere 5.6, per esempio, il rilascio
|
|
|
|
che emerge al termine della finestra d'inclusione si chiamerà 5.6-rc1.
|
2018-12-02 10:40:10 -07:00
|
|
|
Questo rilascio indica che il momento di aggiungere nuovi componenti è
|
|
|
|
passato, e che è iniziato il periodo di stabilizzazione del prossimo kernel.
|
|
|
|
|
|
|
|
Nelle successive sei/dieci settimane, potranno essere sottoposte solo modifiche
|
|
|
|
che vanno a risolvere delle problematiche. Occasionalmente potrà essere
|
|
|
|
consentita una modifica più consistente, ma tali occasioni sono rare.
|
|
|
|
Gli sviluppatori che tenteranno di aggiungere nuovi elementi al di fuori della
|
|
|
|
finestra di inclusione, tendenzialmente, riceveranno un accoglienza poco
|
|
|
|
amichevole. Come regola generale: se vi perdete la finestra di inclusione per
|
|
|
|
un dato componente, la cosa migliore da fare è aspettare il ciclo di sviluppo
|
|
|
|
successivo (un'eccezione può essere fatta per i driver per hardware non
|
|
|
|
supportati in precedenza; se toccano codice non facente parte di quello
|
|
|
|
attuale, che non causino regressioni e che potrebbero essere aggiunti in
|
|
|
|
sicurezza in un qualsiasi momento)
|
|
|
|
|
|
|
|
Mentre le correzioni si aprono la loro strada all'interno del ramo principale,
|
|
|
|
il ritmo delle modifiche rallenta col tempo. Linus rilascia un nuovo
|
|
|
|
kernel -rc circa una volta alla settimana; e ne usciranno circa 6 o 9 prima
|
|
|
|
che il kernel venga considerato sufficientemente stabile e che il rilascio
|
2020-04-30 15:20:37 -07:00
|
|
|
finale venga fatto. A quel punto tutto il processo ricomincerà.
|
2018-12-02 10:40:10 -07:00
|
|
|
|
2020-04-30 15:20:37 -07:00
|
|
|
Esempio: ecco com'è andato il ciclo di sviluppo della versione 5.4
|
2018-12-02 10:40:10 -07:00
|
|
|
(tutte le date si collocano nel 2018)
|
|
|
|
|
|
|
|
|
|
|
|
============== =======================================
|
2020-04-30 15:20:37 -07:00
|
|
|
15 settembre 5.3 rilascio stabile
|
|
|
|
30 settembre 5.4-rc1, finestra di inclusione chiusa
|
|
|
|
6 ottobre 5.4-rc2
|
|
|
|
13 ottobre 5.4-rc3
|
|
|
|
20 ottobre 5.4-rc4
|
|
|
|
27 ottobre 5.4-rc5
|
|
|
|
3 novembre 5.4-rc6
|
|
|
|
10 novembre 5.4-rc7
|
|
|
|
17 novembre 5.4-rc8
|
|
|
|
24 novembre 5.4 rilascio stabile
|
2018-12-02 10:40:10 -07:00
|
|
|
============== =======================================
|
|
|
|
|
|
|
|
In che modo gli sviluppatori decidono quando chiudere il ciclo di sviluppo e
|
|
|
|
creare quindi una rilascio stabile? Un metro valido è il numero di regressioni
|
|
|
|
rilevate nel precedente rilascio. Nessun baco è il benvenuto, ma quelli che
|
|
|
|
procurano problemi su sistemi che hanno funzionato in passato sono considerati
|
|
|
|
particolarmente seri. Per questa ragione, le modifiche che portano ad una
|
|
|
|
regressione sono viste sfavorevolmente e verranno quasi sicuramente annullate
|
|
|
|
durante il periodo di stabilizzazione.
|
|
|
|
|
|
|
|
L'obiettivo degli sviluppatori è quello di aggiustare tutte le regressioni
|
|
|
|
conosciute prima che avvenga il rilascio stabile. Nel mondo reale, questo
|
|
|
|
tipo di perfezione difficilmente viene raggiunta; esistono troppe variabili
|
|
|
|
in un progetto di questa portata. Arriva un punto dove ritardare il rilascio
|
|
|
|
finale peggiora la situazione; la quantità di modifiche in attesa della
|
|
|
|
prossima finestra di inclusione crescerà enormemente, creando ancor più
|
2020-04-30 15:20:37 -07:00
|
|
|
regressioni al giro successivo. Quindi molti kernel 5.x escono con una
|
2018-12-02 10:40:10 -07:00
|
|
|
manciata di regressioni delle quali, si spera, nessuna è grave.
|
|
|
|
|
|
|
|
Una volta che un rilascio stabile è fatto, il suo costante mantenimento è
|
|
|
|
affidato al "squadra stabilità", attualmente composta da Greg Kroah-Hartman.
|
|
|
|
Questa squadra rilascia occasionalmente degli aggiornamenti relativi al
|
2020-04-30 15:20:37 -07:00
|
|
|
rilascio stabile usando la numerazione 5.x.y. Per essere presa in
|
2018-12-02 10:40:10 -07:00
|
|
|
considerazione per un rilascio d'aggiornamento, una modifica deve:
|
|
|
|
(1) correggere un baco importante (2) essere già inserita nel ramo principale
|
|
|
|
per il prossimo sviluppo del kernel. Solitamente, passato il loro rilascio
|
|
|
|
iniziale, i kernel ricevono aggiornamenti per più di un ciclo di sviluppo.
|
2020-04-30 15:20:37 -07:00
|
|
|
Quindi, per esempio, la storia del kernel 5.2 appare così (anno 2019):
|
2018-12-02 10:40:10 -07:00
|
|
|
|
|
|
|
============== ===============================
|
2020-11-14 01:33:42 -07:00
|
|
|
7 luglio 5.2 rilascio stabile
|
2020-04-30 15:20:37 -07:00
|
|
|
14 luglio 5.2.1
|
|
|
|
21 luglio 5.2.2
|
|
|
|
26 luglio 5.2.3
|
|
|
|
28 luglio 5.2.4
|
|
|
|
31 luglio 5.2.5
|
2018-12-02 10:40:10 -07:00
|
|
|
... ...
|
2020-04-30 15:20:37 -07:00
|
|
|
11 ottobre 5.2.21
|
2018-12-02 10:40:10 -07:00
|
|
|
============== ===============================
|
|
|
|
|
2020-04-30 15:20:37 -07:00
|
|
|
La 5.2.21 fu l'aggiornamento finale per la versione 5.2.
|
2018-12-02 10:40:10 -07:00
|
|
|
|
|
|
|
Alcuni kernel sono destinati ad essere kernel a "lungo termine"; questi
|
2022-12-31 06:08:49 -07:00
|
|
|
riceveranno assistenza per un lungo periodo di tempo. Consultate il seguente
|
|
|
|
collegamento per avere la lista delle versioni attualmente supportate e i
|
|
|
|
relativi manutentori:
|
2018-12-02 10:40:10 -07:00
|
|
|
|
2022-12-31 06:08:49 -07:00
|
|
|
https://www.kernel.org/category/releases.html
|
2018-12-02 10:40:10 -07:00
|
|
|
|
|
|
|
Questa selezione di kernel di lungo periodo sono puramente dovuti ai loro
|
|
|
|
manutentori, alla loro necessità e al tempo per tenere aggiornate proprio
|
|
|
|
quelle versioni. Non ci sono altri kernel a lungo termine in programma per
|
|
|
|
alcun rilascio in arrivo.
|
|
|
|
|
|
|
|
Il ciclo di vita di una patch
|
|
|
|
-----------------------------
|
|
|
|
|
|
|
|
Le patch non passano direttamente dalla tastiera dello sviluppatori
|
|
|
|
al ramo principale del kernel. Esiste, invece, una procedura disegnata
|
|
|
|
per assicurare che ogni patch sia di buona qualità e desiderata nel
|
|
|
|
ramo principale. Questo processo avviene velocemente per le correzioni
|
|
|
|
meno importanti, o, nel caso di patch ampie e controverse, va avanti per anni.
|
|
|
|
Per uno sviluppatore la maggior frustrazione viene dalla mancanza di
|
|
|
|
comprensione di questo processo o dai tentativi di aggirarlo.
|
|
|
|
|
|
|
|
Nella speranza di ridurre questa frustrazione, questo documento spiegherà
|
|
|
|
come una patch viene inserita nel kernel. Ciò che segue è un'introduzione
|
|
|
|
che descrive il processo ideale. Approfondimenti verranno invece trattati
|
|
|
|
più avanti.
|
|
|
|
|
|
|
|
Una patch attraversa, generalmente, le seguenti fasi:
|
|
|
|
|
|
|
|
- Progetto. In questa fase sono stabilite quelli che sono i requisiti
|
|
|
|
della modifica - e come verranno soddisfatti. Il lavoro di progettazione
|
|
|
|
viene spesso svolto senza coinvolgere la comunità, ma è meglio renderlo
|
|
|
|
il più aperto possibile; questo può far risparmiare molto tempo evitando
|
|
|
|
eventuali riprogettazioni successive.
|
|
|
|
|
|
|
|
- Prima revisione. Le patch vengono pubblicate sulle liste di discussione
|
|
|
|
interessate, e gli sviluppatori in quella lista risponderanno coi loro
|
|
|
|
commenti. Se si svolge correttamente, questo procedimento potrebbe far
|
|
|
|
emergere problemi rilevanti in una patch.
|
|
|
|
|
|
|
|
- Revisione più ampia. Quando la patch è quasi pronta per essere inserita
|
|
|
|
nel ramo principale, un manutentore importante del sottosistema dovrebbe
|
|
|
|
accettarla - anche se, questa accettazione non è una garanzia che la
|
|
|
|
patch arriverà nel ramo principale. La patch sarà visibile nei sorgenti
|
|
|
|
del sottosistema in questione e nei sorgenti -next (descritti sotto).
|
|
|
|
Quando il processo va a buon fine, questo passo porta ad una revisione
|
|
|
|
più estesa della patch e alla scoperta di problemi d'integrazione
|
|
|
|
con il lavoro altrui.
|
|
|
|
|
|
|
|
- Per favore, tenete da conto che la maggior parte dei manutentori ha
|
|
|
|
anche un lavoro quotidiano, quindi integrare le vostre patch potrebbe
|
|
|
|
non essere la loro priorità più alta. Se una vostra patch riceve
|
|
|
|
dei suggerimenti su dei cambiamenti necessari, dovreste applicare
|
|
|
|
quei cambiamenti o giustificare perché non sono necessari. Se la vostra
|
|
|
|
patch non riceve alcuna critica ma non è stata integrata dal
|
|
|
|
manutentore del driver o sottosistema, allora dovreste continuare con
|
|
|
|
i necessari aggiornamenti per mantenere la patch aggiornata al kernel
|
|
|
|
più recente cosicché questa possa integrarsi senza problemi; continuate
|
|
|
|
ad inviare gli aggiornamenti per essere revisionati e integrati.
|
|
|
|
|
|
|
|
- Inclusione nel ramo principale. Eventualmente, una buona patch verrà
|
|
|
|
inserita all'interno nel repositorio principale, gestito da
|
|
|
|
Linus Torvalds. In questa fase potrebbero emergere nuovi problemi e/o
|
|
|
|
commenti; è importante che lo sviluppatore sia collaborativo e che sistemi
|
|
|
|
ogni questione che possa emergere.
|
|
|
|
|
|
|
|
- Rilascio stabile. Ora, il numero di utilizzatori che sono potenzialmente
|
|
|
|
toccati dalla patch è aumentato, quindi, ancora una volta, potrebbero
|
|
|
|
emergere nuovi problemi.
|
|
|
|
|
|
|
|
- Manutenzione di lungo periodo. Nonostante sia possibile che uno sviluppatore
|
|
|
|
si dimentichi del codice dopo la sua integrazione, questo comportamento
|
|
|
|
lascia una brutta impressione nella comunità di sviluppo. Integrare il
|
|
|
|
codice elimina alcuni degli oneri facenti parte della manutenzione, in
|
|
|
|
particolare, sistemerà le problematiche causate dalle modifiche all'API.
|
|
|
|
Ma lo sviluppatore originario dovrebbe continuare ad assumersi la
|
|
|
|
responsabilità per il codice se quest'ultimo continua ad essere utile
|
|
|
|
nel lungo periodo.
|
|
|
|
|
|
|
|
Uno dei più grandi errori fatti dagli sviluppatori kernel (o dai loro datori
|
|
|
|
di lavoro) è quello di cercare di ridurre tutta la procedura ad una singola
|
|
|
|
"integrazione nel remo principale". Questo approccio inevitabilmente conduce
|
|
|
|
a una condizione di frustrazione per tutti coloro che sono coinvolti.
|
|
|
|
|
|
|
|
Come le modifiche finiscono nel Kernel
|
|
|
|
--------------------------------------
|
|
|
|
|
|
|
|
Esiste una sola persona che può inserire le patch nel repositorio principale
|
2020-04-30 15:20:37 -07:00
|
|
|
del kernel: Linus Torvalds. Ma, per esempio, di tutte le 9500 patch
|
|
|
|
che entrarono nella versione 2.6.38 del kernel, solo 112 (circa
|
|
|
|
l'1,3%) furono scelte direttamente da Linus in persona. Il progetto
|
|
|
|
del kernel è cresciuto fino a raggiungere una dimensione tale per cui
|
|
|
|
un singolo sviluppatore non può controllare e selezionare
|
|
|
|
indipendentemente ogni modifica senza essere supportato. La via
|
|
|
|
scelta dagli sviluppatori per indirizzare tale crescita è stata quella
|
2018-12-02 10:40:10 -07:00
|
|
|
di utilizzare un sistema di "sottotenenti" basato sulla fiducia.
|
|
|
|
|
|
|
|
Il codice base del kernel è spezzato in una serie si sottosistemi: rete,
|
|
|
|
supporto per specifiche architetture, gestione della memoria, video e
|
|
|
|
strumenti, etc. Molti sottosistemi hanno un manutentore designato: ovvero uno
|
|
|
|
sviluppatore che ha piena responsabilità di tutto il codice presente in quel
|
|
|
|
sottosistema. Tali manutentori di sottosistema sono i guardiani
|
|
|
|
(in un certo senso) della parte di kernel che gestiscono; sono coloro che
|
|
|
|
(solitamente) accetteranno una patch per l'inclusione nel ramo principale
|
|
|
|
del kernel.
|
|
|
|
|
|
|
|
I manutentori di sottosistema gestiscono ciascuno la propria parte dei sorgenti
|
|
|
|
del kernel, utilizzando abitualmente (ma certamente non sempre) git.
|
|
|
|
Strumenti come git (e affini come quilt o mercurial) permettono ai manutentori
|
|
|
|
di stilare una lista delle patch, includendo informazioni sull'autore ed
|
|
|
|
altri metadati. In ogni momento, il manutentore può individuare quale patch
|
|
|
|
nel sua repositorio non si trova nel ramo principale.
|
|
|
|
|
|
|
|
Quando la "finestra di integrazione" si apre, i manutentori di alto livello
|
|
|
|
chiederanno a Linus di "prendere" dai loro repositori le modifiche che hanno
|
|
|
|
selezionato per l'inclusione. Se Linus acconsente, il flusso di patch si
|
|
|
|
convoglierà nel repositorio di quest ultimo, divenendo così parte del ramo
|
|
|
|
principale del kernel. La quantità d'attenzione che Linus presta alle
|
|
|
|
singole patch ricevute durante l'operazione di integrazione varia.
|
|
|
|
È chiaro che, qualche volta, guardi più attentamente. Ma, come regola
|
|
|
|
generale, Linus confida nel fatto che i manutentori di sottosistema non
|
|
|
|
selezionino pessime patch.
|
|
|
|
|
|
|
|
I manutentori di sottosistemi, a turno, possono "prendere" patch
|
|
|
|
provenienti da altri manutentori. Per esempio, i sorgenti per la rete rete
|
|
|
|
sono costruiti da modifiche che si sono accumulate inizialmente nei sorgenti
|
|
|
|
dedicati ai driver per dispositivi di rete, rete senza fili, ecc. Tale
|
|
|
|
catena di repositori può essere più o meno lunga, benché raramente ecceda
|
|
|
|
i due o tre collegamenti. Questo processo è conosciuto come
|
|
|
|
"la catena della fiducia", perché ogni manutentore all'interno della
|
|
|
|
catena si fida di coloro che gestiscono i livelli più bassi.
|
|
|
|
|
|
|
|
Chiaramente, in un sistema come questo, l'inserimento delle patch all'interno
|
|
|
|
del kernel si basa sul trovare il manutentore giusto. Di norma, inviare
|
|
|
|
patch direttamente a Linus non è la via giusta.
|
|
|
|
|
|
|
|
|
|
|
|
Sorgenti -next
|
|
|
|
--------------
|
|
|
|
|
|
|
|
La catena di sottosistemi guida il flusso di patch all'interno del kernel,
|
|
|
|
ma solleva anche un interessante quesito: se qualcuno volesse vedere tutte le
|
|
|
|
patch pronte per la prossima finestra di integrazione?
|
|
|
|
Gli sviluppatori si interesseranno alle patch in sospeso per verificare
|
|
|
|
che non ci siano altri conflitti di cui preoccuparsi; una modifica che, per
|
|
|
|
esempio, cambia il prototipo di una funzione fondamentale del kernel andrà in
|
|
|
|
conflitto con qualsiasi altra modifica che utilizzi la vecchia versione di
|
|
|
|
quella funzione. Revisori e tester vogliono invece avere accesso alle
|
|
|
|
modifiche nella loro totalità prima che approdino nel ramo principale del
|
|
|
|
kernel. Uno potrebbe prendere le patch provenienti da tutti i sottosistemi
|
|
|
|
d'interesse, ma questo sarebbe un lavoro enorme e fallace.
|
|
|
|
|
|
|
|
La risposta ci viene sotto forma di sorgenti -next, dove i sottosistemi sono
|
|
|
|
raccolti per essere testati e controllati. Il più vecchio di questi sorgenti,
|
|
|
|
gestito da Andrew Morton, è chiamato "-mm" (memory management, che è l'inizio
|
|
|
|
di tutto). L'-mm integra patch proveniente da una lunga lista di sottosistemi;
|
|
|
|
e ha, inoltre, alcune patch destinate al supporto del debugging.
|
|
|
|
|
|
|
|
Oltre a questo, -mm contiene una raccolta significativa di patch che sono
|
|
|
|
state selezionate da Andrew direttamente. Queste patch potrebbero essere
|
|
|
|
state inviate in una lista di discussione, o possono essere applicate ad una
|
|
|
|
parte del kernel per la quale non esiste un sottosistema dedicato.
|
|
|
|
Di conseguenza, -mm opera come una specie di sottosistema "ultima spiaggia";
|
|
|
|
se per una patch non esiste una via chiara per entrare nel ramo principale,
|
|
|
|
allora è probabile che finirà in -mm. Le patch passate per -mm
|
|
|
|
eventualmente finiranno nel sottosistema più appropriato o saranno inviate
|
|
|
|
direttamente a Linus. In un tipico ciclo di sviluppo, circa il 5-10% delle
|
|
|
|
patch andrà nel ramo principale attraverso -mm.
|
|
|
|
|
|
|
|
La patch -mm correnti sono disponibili nella cartella "mmotm" (-mm of
|
|
|
|
the moment) all'indirizzo:
|
|
|
|
|
|
|
|
http://www.ozlabs.org/~akpm/mmotm/
|
|
|
|
|
|
|
|
È molto probabile che l'uso dei sorgenti MMOTM diventi un'esperienza
|
|
|
|
frustrante; ci sono buone probabilità che non compili nemmeno.
|
|
|
|
|
|
|
|
I sorgenti principali per il prossimo ciclo d'integrazione delle patch
|
|
|
|
è linux-next, gestito da Stephen Rothwell. I sorgenti linux-next sono, per
|
|
|
|
definizione, un'istantanea di come dovrà apparire il ramo principale dopo che
|
|
|
|
la prossima finestra di inclusione si chiuderà. I linux-next sono annunciati
|
|
|
|
sulla lista di discussione linux-kernel e linux-next nel momento in cui
|
|
|
|
vengono assemblati; e possono essere scaricate da:
|
|
|
|
|
|
|
|
http://www.kernel.org/pub/linux/kernel/next/
|
|
|
|
|
|
|
|
Linux-next è divenuto parte integrante del processo di sviluppo del kernel;
|
|
|
|
tutte le patch incorporate durante una finestra di integrazione dovrebbero
|
|
|
|
aver trovato la propria strada in linux-next, a volte anche prima dell'apertura
|
|
|
|
della finestra di integrazione.
|
|
|
|
|
|
|
|
|
|
|
|
Sorgenti in preparazione
|
|
|
|
------------------------
|
|
|
|
|
|
|
|
Nei sorgenti del kernel esiste la cartella drivers/staging/, dove risiedono
|
|
|
|
molte sotto-cartelle per i driver o i filesystem che stanno per essere aggiunti
|
|
|
|
al kernel. Questi restano nella cartella drivers/staging fintanto che avranno
|
|
|
|
bisogno di maggior lavoro; una volta completato, possono essere spostate
|
|
|
|
all'interno del kernel nel posto più appropriato. Questo è il modo di tener
|
|
|
|
traccia dei driver che non sono ancora in linea con gli standard di codifica
|
|
|
|
o qualità, ma che le persone potrebbero voler usare ugualmente e tracciarne
|
|
|
|
lo sviluppo.
|
|
|
|
|
|
|
|
Greg Kroah-Hartman attualmente gestisce i sorgenti in preparazione. I driver
|
|
|
|
che non sono completamente pronti vengono inviati a lui, e ciascun driver avrà
|
|
|
|
la propria sotto-cartella in drivers/staging/. Assieme ai file sorgenti
|
|
|
|
dei driver, dovrebbe essere presente nella stessa cartella anche un file TODO.
|
|
|
|
Il file TODO elenca il lavoro ancora da fare su questi driver per poter essere
|
|
|
|
accettati nel kernel, e indica anche la lista di persone da inserire in copia
|
|
|
|
conoscenza per ogni modifica fatta. Le regole attuali richiedono che i
|
|
|
|
driver debbano, come minimo, compilare adeguatamente.
|
|
|
|
|
|
|
|
La *preparazione* può essere una via relativamente facile per inserire nuovi
|
|
|
|
driver all'interno del ramo principale, dove, con un po' di fortuna, saranno
|
|
|
|
notati da altri sviluppatori e migliorati velocemente. Entrare nella fase
|
|
|
|
di preparazione non è però la fine della storia, infatti, il codice che si
|
|
|
|
trova nella cartella staging che non mostra regolari progressi potrebbe
|
|
|
|
essere rimosso. Le distribuzioni, inoltre, tendono a dimostrarsi relativamente
|
|
|
|
riluttanti nell'attivare driver in preparazione. Quindi lo preparazione è,
|
|
|
|
nel migliore dei casi, una tappa sulla strada verso il divenire un driver
|
|
|
|
del ramo principale.
|
|
|
|
|
|
|
|
|
|
|
|
Strumenti
|
|
|
|
---------
|
|
|
|
|
|
|
|
Come è possibile notare dal testo sopra, il processo di sviluppo del kernel
|
|
|
|
dipende pesantemente dalla capacità di guidare la raccolta di patch in
|
|
|
|
diverse direzioni. L'intera cosa non funzionerebbe se non venisse svolta
|
|
|
|
con l'uso di strumenti appropriati e potenti. Spiegare l'uso di tali
|
|
|
|
strumenti non è lo scopo di questo documento, ma c'è spazio per alcuni
|
|
|
|
consigli.
|
|
|
|
|
|
|
|
In assoluto, nella comunità del kernel, predomina l'uso di git come sistema
|
|
|
|
di gestione dei sorgenti. Git è una delle diverse tipologie di sistemi
|
|
|
|
distribuiti di controllo versione che sono stati sviluppati nella comunità
|
|
|
|
del software libero. Esso è calibrato per lo sviluppo del kernel, e si
|
|
|
|
comporta abbastanza bene quando ha a che fare con repositori grandi e con un
|
|
|
|
vasto numero di patch. Git ha inoltre la reputazione di essere difficile
|
|
|
|
da imparare e utilizzare, benché stia migliorando. Agli sviluppatori
|
|
|
|
del kernel viene richiesta un po' di familiarità con git; anche se non lo
|
|
|
|
utilizzano per il proprio lavoro, hanno bisogno di git per tenersi al passo
|
|
|
|
con il lavoro degli altri sviluppatori (e con il ramo principale).
|
|
|
|
|
|
|
|
Git è ora compreso in quasi tutte le distribuzioni Linux. Esiste una sito che
|
|
|
|
potete consultare:
|
|
|
|
|
|
|
|
http://git-scm.com/
|
|
|
|
|
|
|
|
Qui troverete i riferimenti alla documentazione e alle guide passo-passo.
|
|
|
|
|
|
|
|
Tra gli sviluppatori Kernel che non usano git, la scelta alternativa più
|
|
|
|
popolare è quasi sicuramente Mercurial:
|
|
|
|
|
|
|
|
http://www.selenic.com/mercurial/
|
|
|
|
|
|
|
|
Mercurial condivide diverse caratteristiche con git, ma fornisce
|
|
|
|
un'interfaccia che potrebbe risultare più semplice da utilizzare.
|
|
|
|
|
|
|
|
L'altro strumento che vale la pena conoscere è Quilt:
|
|
|
|
|
|
|
|
http://savannah.nongnu.org/projects/quilt/
|
|
|
|
|
|
|
|
|
|
|
|
Quilt è un sistema di gestione delle patch, piuttosto che un sistema
|
|
|
|
di gestione dei sorgenti. Non mantiene uno storico degli eventi; ma piuttosto
|
|
|
|
è orientato verso il tracciamento di uno specifico insieme di modifiche
|
|
|
|
rispetto ad un codice in evoluzione. Molti dei più grandi manutentori di
|
|
|
|
sottosistema utilizzano quilt per gestire le patch che dovrebbero essere
|
|
|
|
integrate. Per la gestione di certe tipologie di sorgenti (-mm, per esempio),
|
|
|
|
quilt è il miglior strumento per svolgere il lavoro.
|
|
|
|
|
|
|
|
|
|
|
|
Liste di discussione
|
|
|
|
--------------------
|
|
|
|
|
|
|
|
Una grossa parte del lavoro di sviluppo del Kernel Linux viene svolto tramite
|
|
|
|
le liste di discussione. È difficile essere un membro della comunità
|
|
|
|
pienamente coinvolto se non si partecipa almeno ad una lista da qualche
|
|
|
|
parte. Ma, le liste di discussione di Linux rappresentano un potenziale
|
|
|
|
problema per gli sviluppatori, che rischiano di venir sepolti da un mare di
|
|
|
|
email, restare incagliati nelle convenzioni in vigore nelle liste Linux,
|
|
|
|
o entrambi.
|
|
|
|
|
|
|
|
Molte delle liste di discussione del Kernel girano su vger.kernel.org;
|
|
|
|
l'elenco principale lo si trova sul sito:
|
|
|
|
|
|
|
|
http://vger.kernel.org/vger-lists.html
|
|
|
|
|
|
|
|
Esistono liste gestite altrove; un certo numero di queste sono in
|
2020-11-14 01:33:42 -07:00
|
|
|
redhat.com/mailman/listinfo.
|
2018-12-02 10:40:10 -07:00
|
|
|
|
|
|
|
La lista di discussione principale per lo sviluppo del kernel è, ovviamente,
|
|
|
|
linux-kernel. Questa lista è un luogo ostile dove trovarsi; i volumi possono
|
|
|
|
raggiungere i 500 messaggi al giorno, la quantità di "rumore" è elevata,
|
|
|
|
la conversazione può essere strettamente tecnica e i partecipanti non sono
|
|
|
|
sempre preoccupati di mostrare un alto livello di educazione. Ma non esiste
|
|
|
|
altro luogo dove la comunità di sviluppo del kernel si unisce per intero;
|
|
|
|
gli sviluppatori che evitano tale lista si perderanno informazioni importanti.
|
|
|
|
|
|
|
|
Ci sono alcuni consigli che possono essere utili per sopravvivere a
|
|
|
|
linux-kernel:
|
|
|
|
|
|
|
|
- Tenete la lista in una cartella separata, piuttosto che inserirla nella
|
|
|
|
casella di posta principale. Così da essere in grado di ignorare il flusso
|
|
|
|
di mail per un certo periodo di tempo.
|
|
|
|
|
|
|
|
- Non cercate di seguire ogni conversazione - nessuno lo fa. È importante
|
|
|
|
filtrare solo gli argomenti d'interesse (sebbene va notato che le
|
|
|
|
conversazioni di lungo periodo possono deviare dall'argomento originario
|
|
|
|
senza cambiare il titolo della mail) e le persone che stanno partecipando.
|
|
|
|
|
|
|
|
- Non alimentate i troll. Se qualcuno cerca di creare nervosismo, ignoratelo.
|
|
|
|
|
|
|
|
- Quando rispondete ad una mail linux-kernel (o ad altre liste) mantenete
|
|
|
|
tutti i Cc:. In assenza di importanti motivazioni (come una richiesta
|
|
|
|
esplicita), non dovreste mai togliere destinatari. Assicuratevi sempre che
|
|
|
|
la persona alla quale state rispondendo sia presente nella lista Cc. Questa
|
|
|
|
usanza fa si che divenga inutile chiedere esplicitamente di essere inseriti
|
|
|
|
in copia nel rispondere al vostro messaggio.
|
|
|
|
|
|
|
|
- Cercate nell'archivio della lista (e nella rete nella sua totalità) prima
|
|
|
|
di far domande. Molti sviluppatori possono divenire impazienti con le
|
|
|
|
persone che chiaramente non hanno svolto i propri compiti a casa.
|
|
|
|
|
2024-03-16 15:54:00 -07:00
|
|
|
- Rispondete sotto alla porzione di righe citate, così da dare un contesto alle
|
|
|
|
vostre risposte, e quindi renderle più leggibili (in altre parole, evitate di
|
|
|
|
rispondere in cima, ovvero prima del testo citato). Per maggiori dettagli
|
|
|
|
leggete :ref:`Documentation/translations/it_IT/process/submitting-patches.rst
|
|
|
|
<it_interleaved_replies>`.
|
|
|
|
|
2018-12-02 10:40:10 -07:00
|
|
|
|
|
|
|
- Chiedete nella lista di discussione corretta. Linux-kernel può essere un
|
|
|
|
punto di incontro generale, ma non è il miglior posto dove trovare
|
|
|
|
sviluppatori da tutti i sottosistemi.
|
|
|
|
|
|
|
|
Infine, la ricerca della corretta lista di discussione è uno degli errori più
|
|
|
|
comuni per gli sviluppatori principianti. Qualcuno che pone una domanda
|
|
|
|
relativa alla rete su linux-kernel riceverà quasi certamente il suggerimento
|
|
|
|
di chiedere sulla lista netdev, che è la lista frequentata dagli sviluppatori
|
|
|
|
di rete. Ci sono poi altre liste per i sottosistemi SCSI, video4linux, IDE,
|
|
|
|
filesystem, etc. Il miglior posto dove cercare una lista di discussione è il
|
|
|
|
file MAINTAINERS che si trova nei sorgenti del kernel.
|
|
|
|
|
|
|
|
Iniziare con lo sviluppo del Kernel
|
|
|
|
-----------------------------------
|
|
|
|
|
|
|
|
Sono comuni le domande sul come iniziare con lo sviluppo del kernel - sia da
|
|
|
|
singole persone che da aziende. Altrettanto comuni sono i passi falsi che
|
|
|
|
rendono l'inizio di tale relazione più difficile di quello che dovrebbe essere.
|
|
|
|
|
|
|
|
Le aziende spesso cercano di assumere sviluppatori noti per creare un gruppo
|
|
|
|
di sviluppo iniziale. Questo, in effetti, può essere una tecnica efficace.
|
|
|
|
Ma risulta anche essere dispendiosa e non va ad accrescere il bacino di
|
|
|
|
sviluppatori kernel con esperienza. È possibile anche "portare a casa"
|
|
|
|
sviluppatori per accelerare lo sviluppo del kernel, dando comunque
|
|
|
|
all'investimento un po' di tempo. Prendersi questo tempo può fornire
|
|
|
|
al datore di lavoro un gruppo di sviluppatori che comprendono sia il kernel
|
|
|
|
che l'azienda stessa, e che possono supportare la formazione di altre persone.
|
|
|
|
Nel medio periodo, questa è spesso uno delle soluzioni più proficue.
|
|
|
|
|
|
|
|
I singoli sviluppatori sono spesso, comprensibilmente, una perdita come punto
|
|
|
|
di partenza. Iniziare con un grande progetto può rivelarsi intimidatorio;
|
|
|
|
spesso all'inizio si vuole solo verificare il terreno con qualcosa di piccolo.
|
|
|
|
Questa è una delle motivazioni per le quali molti sviluppatori saltano alla
|
|
|
|
creazione di patch che vanno a sistemare errori di battitura o
|
|
|
|
problematiche minori legate allo stile del codice. Sfortunatamente, tali
|
|
|
|
patch creano un certo livello di rumore che distrae l'intera comunità di
|
|
|
|
sviluppo, quindi, sempre di più, esse vengono degradate. I nuovi sviluppatori
|
|
|
|
che desiderano presentarsi alla comunità non riceveranno l'accoglienza
|
|
|
|
che vorrebbero con questi mezzi.
|
|
|
|
|
|
|
|
Andrew Morton da questo consiglio agli aspiranti sviluppatori kernel
|
|
|
|
|
|
|
|
::
|
|
|
|
|
|
|
|
Il primo progetto per un neofita del kernel dovrebbe essere
|
|
|
|
sicuramente quello di "assicurarsi che il kernel funzioni alla
|
|
|
|
perfezione sempre e su tutte le macchine sulle quali potete stendere
|
|
|
|
la vostra mano". Solitamente il modo per fare ciò è quello di
|
|
|
|
collaborare con gli altri nel sistemare le cose (questo richiede
|
|
|
|
persistenza!) ma va bene - è parte dello sviluppo kernel.
|
|
|
|
|
|
|
|
(http://lwn.net/Articles/283982/).
|
|
|
|
|
|
|
|
In assenza di problemi ovvi da risolvere, si consiglia agli sviluppatori
|
|
|
|
di consultare, in generale, la lista di regressioni e di bachi aperti.
|
|
|
|
Non c'è mai carenza di problematiche bisognose di essere sistemate;
|
|
|
|
accollandosi tali questioni gli sviluppatori accumuleranno esperienza con
|
|
|
|
la procedura, ed allo stesso tempo, aumenteranno la loro rispettabilità
|
|
|
|
all'interno della comunità di sviluppo.
|