Perché non far uscire Ubuntu ogni mese, anziché ogni sei? È questa la proposta di Scott James Remnant, membro del consiglio tecnico della famosa distribuzione Linux e attualmente alle dipendenze di Google. Un Ubuntu in stile Chrome e Firefox, due browser che sono aggiornati con cadenza serrata e regolare.
Gli utenti di Ubuntu sanno bene che il sistema operativo viene aggiornato ad aprile e a ottobre. Il supporto alle versioni è di 18 mesi, ma per la versioni LTS (long term support, escono ogni due anni) passa a 3 anni per la variante desktop e 5 anni per quella server.

Sei mesi sono una via di mezzo che in molti ritengono accettabile, in quanto impedisce che i tempi si dilunghino eccessivamente (il team di Canonical è molto scrupoloso sul rispetto delle date). Inoltre si assicura l'uscita di novità a "getto continuo".
Altri ritengono che però una data fissa sia controproducente: se per un motivo o per l'altro c'è un problema, pur di rispettare la scaletta vi si passa sopra, rimandando le correzioni a dopo l'uscita con piccoli aggiornamenti, oppure alla versione successiva. Inoltre c'è la possibilità che il team, pur di rispettare i tempi, includa software di terze parti non ancora propriamente stabile, come per esempio un browser in versione beta.
Secondo Remnant il miglior compromesso sarebbe passare a un ciclo di uscita mensile, con la creazione di tre canali di sviluppo paralleli: alpha, beta e release (versione stabile). L'alpha sarebbe dedicata a un ristretto gruppo di sviluppatori, la beta potrebbe essere il canale per gli utenti che vogliono contribuire a testare le novità introdotte e infine la release stabile, quella dedicata tutti coloro che vogliono un prodotto "finito". Le versioni LTS dovranno invece continuare a seguire una cadenza biennale, in modo che vi sia ancora ecosistema stabile per le aziende e gli OEM.
Oggi passano sei mesi da una versione all'altra di Ubuntu
Remnant ritiene che legare le caratteristiche a versioni specifiche non sia la migliore strada per gestire i tempi e soprattutto la qualità. Tanti progetti inoltre non vengono iniziati e poi accantonati, o non iniziati affatto, perché non possono essere realizzati nei tempi previsti. A suo dire il problema sarebbe anche aggravato dalla tendenza di Canonical di legare la paga e i bonus dei dipendenti allo sviluppo della funzione assegnata, che deve essere pronta nei tempi previsti.
Capita così che durante la scrittura del software si corra e nel sistema operativo sia inserita una nuova caratteristica - spesso importante - non del tutto completa, che sarà affinata solo successivamente. Tra gli esempi troviamo Unity o Ubuntu Software Center. Questo è un male per diverse ragioni, in quanto può influire sulla percezione delle nuove caratteristiche da parte dell'utente: una funzione con dei bug, per quanto promettente, potrebbe infastidire chi la usa a tal punto da sovvertirne il parere.
Novità mensili assicurerebbero un sistema in costante evoluzione, permetterebbero agli sviluppatori di lavorare senza fretta e con il sistema dei canali si creerebbe un sisema di testing strutturato fino al rilascio finale. Tuttavia c'è chi come Arstechnica ritiene che l'approccio proposto da Remnant non sia dei migliori o comunque attuabile, in quanto bisognerebbe far sì che i diversi componenti mantengano uno sviluppo allineato.
Una caratteristica potrebbe progredire troppo rispetto a un'altra, dando vita a un prodotto non uniforme, di qualità complessiva non adeguata e con possibili incompatibilità. Insomma problemi. Con sei mesi di tempo, invece, si riesce a far marciare tutto il processo di sviluppo su binari ben precisi, anche per quanto riguarda i software di terze parti, che in questo modo possono garantire la compatibilità con la nuova versione. Cosa che però potrebbe divenire complicata suddividendo lo sviluppo in tre tronconi e accelerando l'uscita delle nuove funzioni.
E voi cari lettori e utenti di Ubuntu che ne pensate della proposta di Remnant? Cosa cambiereste nel ciclo di sviluppo della distribuzione desktop più popolare?

Commenti dei lettori (48)
Se fanno a rilasci mensili, spero che snelliscano il processo di aggiornamento (visto che dovrà essere fatto più frequentemente) e che non facciano la pompamagna ogni volta come Mozilla.
cmq in realtà da "fan" (se cosi mi posso definire) di windows, preferirei pure il ciclo di rilascio a 6 mesi, almeno per i novizi c'è meno confusione etc
Ma per un team come canonical che unizza patch personalizzate e backport della pacchettizzazione, è improponibile un sistema rolling. Troppo impegno grandi problemi. In arch si utilizzano pacchetti vanilla e patch in upstream. Il sistema rolling va alla grande per questo.
Se leggi l'articolo in inglese il quadro è più chiaro.
Il tizio dice che ora tutto è incentrato sul rilascio di 6 mesi: ogni 6 mesi serve una novità, tipo Unity, quindi c'è un fiorire di progetti la cui realizzazione possa essere fatta in 13 settimana, se ci vuole di più viene abbandonato o nemmeno cominciato.
Con un rilascio mensile intenderebbe semplicemente di aggiornare sources.list con uno nuovo che di dia l'accesso a nuovi kernel e così via.
Con un rilascio mensile non ci sarebbe più la corsa dietro a progetti da fare in 13 mesi, ma si farebbero le cose che si vogliono fare, liberamente e senza costrizioni di tempo.
Con un rilascio mensile l'idea è di comportarsi "normalmente" ed ogni 6 mesi fare un semplice freeze.
Una al mese mi pare troppo, soprattutto quando l'aggiornamento dura 1 ora e mezza alla volta