Ad Akademy 2008, i membri della squadra dei rilasci, Sebastian Kügler e Dirk Müller, hanno discusso sul futuro del processo di sviluppo di KDE. Descrivendo le sfide che KDE affronta e proponendo delle soluzioni, hanno generato molte discussioni. Continua a leggere se ti interessa conoscere i dettagli.

Il modello attuale di sviluppo è stato usato per oltre 10 anni. Qualche anno fa si passò a Subversion, e ora si usa CMake, ma fondamentalmente si lavora ancora come si faceva anni fa: solo alcuni strumenti sono leggermente cambiati. I tempi stanno cambiando. Guardiamo i numeri:

Anche l'Akademy di quest'anno è stato uno degli eventi KDE più grossi che si siamo mai tenuti, con più di 350 visitatori provenienti da ogni continente del mondo.

Questa enorme crescita porta a delle conseguenze sia per la vasta comunità, sia per gli sviluppatori, che per la squadra di rilascio. Le patch devono essere controllate, il loro stato deve essere tracciato - queste cose diventano progressivamente più difficili quando la dimensione del progetto cresce nel modo in cui avviene attualmente. Il sistema di sviluppo centralizzato nel trunk di Subversion non è molto adatto a uno sviluppo organizzato in squadre, e il ciclo di rilascio ogni 6 mesi - in teoria ne permette 4 di sviluppo vero e proprio e 2 per stabilizzare il tutto - spesso si riduce appena al 50% del tempo disponibile che serve per sviluppare delle nuove funzionalità.

Il sistema di controllo di revisione attuale di KDE non permette i depositi non in linea, complicando la vita alle persone che non dispongono di una connessione internet stabile, inoltre si è ancora alla ricerca di un maggior numero di partecipanti, quindi ridurre le difficoltà per le nuove persone che si mettono a disposizione è un'altra attività importante da tenere in considerazione.

Modifica dei requisiti

Dovremo permettere una maggior varietà e dovremmo poter favorire flussi di lavoro individuali. Non tutti sono felici con un piano semestrale, non tutti preferiscono Subversion. Le società hanno i propri piani e obblighi, e ciò che è stabile per un utente o per uno sviluppatore non è adatto all'altro. Nel frattempo, nuovi strumenti di sviluppo hanno fatto la loro comparsa, come lo strumento di controllo di revisione distribuito da molti osannato Git. Insieme ai nuovi strumenti di collaborazione, stanno emergendo nuovi modelli. KDE si trova nel processo di adozione di un maggior insieme di dispositivi hardware, Sistemi operativi (OpenSolaris, Windows, Mac OS) e piattaforme mobili come Maemo. E si ha una maggior necessità di stringere collaborazioni efficienti e flessibili con terze parti e altri progetti di Software Libero.
Sebastian e Dirk credono che sia giunta l'ora di impostare un nuovo modo di lavorare. Dal loro punto di vista, il processo di sviluppo di KDE dovrebbe essere elastico, distribuito, e i 'freeze' nel trunk dovrebbero essere evitati quando possibile. Mentre ci sono ancora molte cose da focalizzare nella loro proposta, KDE ha bisogno di essere pronto per il futuro e per l'ulteriore crescita.

Sviluppo elastico

L'idea principale dietro uno Sviluppo elastico è "credere nelle persone". Le regole sono lì per evitare il caos, e per guidare (ma non forzare) le persone in una certa direzione.

Cosa offrirà uno Sviluppo elastico?

Come lo si può attuare?

Per ottenere quanto ci si propone, si deve riflettere sulle proprie esperienze di sviluppatori e condividere le proprie idee su questa cosa. Il processo dovrebbe essere nei pensieri coscienti. Sebastian e Dirk hanno parlato di una lezione specifica che hanno imparato: i piani raramente evolvono. Come un progetto di Software Libero, non si hanno risorse fisse, e anche se accadesse, il mondo cambia troppo velocemente per permettere di prevedere in modo affidabile e pianificare tutto. Ci si deve adattare. Si deve impostare un processo che abbia come obiettivi adattamento e flessibilità, un processo ottimizzato per modifiche non pianificate.

Queste modifiche vanno rivolte a un'area specifica: il ciclo di rilascio. Attualmente, questo è limitato, fino al punto che quasi strangola il ciclo di sviluppo stesso, così Dirk e Sebastian hanno proposto una soluzione:

"Sempre estate nel trunk"

L'attuale processo di rilascio, rappresentato nel grafico sottostante, può essere descritto usando limitazioni tecniche per correggere quello che è essenzialmente un fatto sociale: portare le persone in una "modalità di rilascio".
Più di 4 mesi per sviluppare funzionalità, poi si entra nella fase di freeze per 2 mesi durante i quali, in modo crescente, si applicano regole precise su ciò che deve essere depositato nel trunk. Ciò essenzialmente forza gli sviluppatori a lavorare per stabilizzare il trunk prima del rilascio. Inoltre, gli sviluppatori hanno necessità di mantenere traccia dello stato corrente del trunk, che cambia a seconda del ciclo di rilascio in cui correntemente è KDE. Allo stesso tempo, molti sviluppatori si lamentano del fatto che Subversion renda più difficile mantenere "work branches" (rami del codice che sono usati per sviluppare e stabilizzare nuove funzionalità o maggiori modifiche del codice), quando si fa la fusione del codice, operazione che impiega diverso tempo e anche perché è un processo che tende a produrre errori.

La proposta dovrebbe, essenzialmente, rimuovere queste limitazioni, invece di contare sulla disciplina nella comunità dove sono tutti allo stesso livello, e concentrarsi sulla stabilità. Per semplificare questi cambiamenti, c'è bisogno che l'utente aiuti: una squadra addetta ai test stabilirà un ciclo di riscontri per gli sviluppatori sulla qualità e sui bug. L'uso di un modello di sviluppo più distribuito permetterebbe maggior flessibilità lavorando in branch (rami), finché non sono stabili a sufficienza da poter essere fusi nel trunk. Il trunk, quindi, deve diventare più stabile e predicibile, per permettere una ramificazione, essenzialmente, in qualsiasi momento. Un insieme di regole e l'intesa comune delle nuove regole del trunk sono necessarie. Anche il passaggio a un sistema di controllo della versione distribuito (che è abbastanza obbligatorio in questo modello di sviluppo) non è così di poco conto come nel precedente passaggio ad altri sistemi di controllo della revisione, da CVS a Subversion. Servono una buona documentazione, guide pratiche migliori, e la giusta infrastruttura. La necessità per un supporto migliore per strumenti (quale Git) nel processo di sviluppo di KDE non viene fuori solo per l'idea di un modello di sviluppo nuovo. Gli sviluppatori si stanno muovendo già verso questi strumenti e ignorano che una tendenza del genere significherebbe che il processo di sviluppo di KDE potrebbe divenire confusionario e, alla fine, difficile da controllare.

Nella visione di Sebastian e Dirk, il sistema attuale di KDE dei rilasci di alpha, beta e release candidate sarà sostituito da un sistema che ha tre pietre miliari:

La Milestone Publish

Questo è il momento in cui si chiede agli sviluppatori di pubblicare i rami che desiderano unire al trunk prima del rilascio. Certo, è importante avere una buona visione d'insieme dei diversi rami in ogni momento per evitare che si verifichino duplicazioni del lavoro e consentire a coloro che sono impegnati nella fase di test di stabilizzare il tutto. Ma la "Milestone Publish" è il momento giusto per dare un'ultima occhiata a ciò che deve essere unito, risolvere problemi, fornire riscontri e infine decidere cosa entrerà e cosa rimarrà fuori. La "Mileston Publish" è essenzialmente la data limite per le nuove funzionalità che sono pianificate per il rilascio successivo.

La Milestone Branch

Questo è il momento in cui ci si separa dal ramo trunk, creando un albero che sarà stabilizzato nei due mesi successivi fino al momento in cui sarà pronto per il rilascio. Gli sviluppatori saranno responsabili per il proprio codice, come al solito, ma è possibile continuare a utilizzare il trunk per lo sviluppo di nuove funzionalità. Per facilitare gli sviluppatori che non desiderano passare da un ramo all'altro, è possibile avere un albero che replichi il modello classico di sviluppo. Gli sviluppatori sono stimolati a supportare la fase di test e stabilizzazione del ramo del prossimo rilascio.

La Milestone Tested

La Milestone "tested" rappresenta la data ultima. Le funzionalità, che non incontrano i criteri, saranno escuse dal rilascio. Il risultante codice base sarà rilasciato come KDE 4.x.0 e gli aggiornamenti sequenziali saranno 4.x.1, 4.x.2, ecc... Dovrebbe essere una buona idea incaricare qualcuni che sarà responsabile per questo rilascio, garantendosi rilasci che correggono bug vari in maniera cadenzata e coordinandosi affinche i backport (ndr.: le correzioni in versioni precedenti esempio: rilascio di KDE 4.2.x. Il backport sarà una correzione anche in KDE 4.1.x) delle correzioni finiscano nel trunk.

Tecnologia

Un prerequisito per questo nuovo modello di sviluppo sarebbe un sistema di gestione del codice sorgente distibuito appropriato. Git ha già rubato il cuore a molti sviluppatori di KDE, ma ci sono altre scelte che dovrebbero essere seriamente valutate. Per di più ci servono strumenti per supportare in modo più semplice il lavoro con i branch e le infrastrutture per pubblicarli. È sempre stata una sfida avere nuovi sviluppatori per revisionare il codice, e dovremmo far si che la cosa sia più semplice possibile. Dovremmo rendere anche più semplice dare un contributo da parte di chi fa test, così da aver pacchetti aggiornati regolarmente per branch specifici come bonus aggiiuntivo. Il trunk serve sempre che sia stabile e compilabile, così da poter usare qualche infrastruttura per test automatizzati.

Si discutono idee come avere alcuni tipo di alberi "prossimo-KDE" contenenti i rami che saranno fusi con il trunk presto; o forse avere alcuni alberi per ogni sottoprogetto in KDE. Un'altra questione è quali criteri si devono seguire per fonderli nel nuovo "trunk". Specialmente in kdelibs, vogliamo assicurare che il codice sia già stabile per mantenere il trunk usabile. Il criterio per fondere in vari moduli deve essere reso chiaro. Cosa succederebbe se del codice cattivo finisse nel trunk? Servono chiare regole. Come lo si può rendere tanto semplice per poter fare la fusione e per tornare indietro in caso di errore (nel caso che il codice che è stato fuso non sia pronto in tempo per un rilascio)?

Avere una pagina su TechBase che publicizzi i differenti rami (compresa una piccola spiegazione del loro obiettivo e informazioni su chi è il responsabile per quel ramo) permetterà una maggior visibilità di detti sorgenti. Bisogna trovare anche una soluzione per il il carico di lavoro che si ha nel gestire il trunk e specialmente se abbiamo rilasci in tempi stretti. Una intera squadra addetta al rilascio deve prendersi delle responsabilità. La versione corrente di KDE è venuta fuori dopo aver trovato i coordinatori dei moduli per le varie parti rilasciate con KDE, ma attualmente non tutti i moduli hanno un responsabile.

Mentre si hanno ancora molte domande inevase, ci piacerebbe elaborarle in collaborazione con la comunità di KDE. Si discute del sistema di controllo delle revisioni di KDE sulla mailing list scm-interest. Le discussione su un livello superiore si possono tenere sulla mailing list della squadra di rilasci e, naturalmente, sul forum principale degli sviluppatori di KDE kde-core-devel.

Con il rilascio di KDE 4.0, la comunità di KDE è entrata nel futuro tecnologicamente. Tuttavia i tempi per le modifiche di cui si è discusso in questo articolo non sono stati ancora decisi, Dirk e Sebastian hanno preso la parola in modo per avere l'opportunità di iniziare una discussione e raffinare queste idee: è tempo che i processi primari di KDE siano fatti più in modo da affrontare il futuro per una nuova fase di crescita in cui ci si ritrova.

--
tradotto da Venturi Giovanni. Tratto da http://dot.kde.org/1219926799/