.. include:: ../disclaimer-ita.rst
:Original: :ref:`Documentation/process/2.Process.rst <development_process>`
:Translator: Alessia Mantegazza <[email protected]>
.. _it_development_process:
Come funziona il processo di sviluppo
=====================================
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.
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:
====== =================
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
====== =================
Ciascun rilascio 5.x è un importante rilascio del kernel con nuove
funzionalità, modifiche interne dell'API, e molto altro. Un tipico
rilascio contiene quasi 13,000 gruppi di modifiche con ulteriori
modifiche a parecchie migliaia di linee di codice. La 5.x. è pertanto la
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.
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.
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
finale venga fatto. A quel punto tutto il processo ricomincerà.
Esempio: ecco com'è andato il ciclo di sviluppo della versione 5.4
(tutte le date si collocano nel 2018)
============== =======================================
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
============== =======================================
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ù
regressioni al giro successivo. Quindi molti kernel 5.x escono con una
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
rilascio stabile usando la numerazione 5.x.y. Per essere presa in
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.
Quindi, per esempio, la storia del kernel 5.2 appare così (anno 2019):
============== ===============================
7 luglio 5.2 rilascio stabile
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
... ...
11 ottobre 5.2.21
============== ===============================
La 5.2.21 fu l'aggiornamento finale per la versione 5.2.
Alcuni kernel sono destinati ad essere kernel a "lungo termine"; questi
riceveranno assistenza per un lungo periodo di tempo. Consultate il seguente
collegamento per avere la lista delle versioni attualmente supportate e i
relativi manutentori:
https://www.kernel.org/category/releases.html
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
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
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
redhat.com/mailman/listinfo.
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.
- 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>`.
- 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.
Codebase Browser
linux