Due developer Debian di vecchia data, Lars Wirzenius e Russ Allbery, hanno pubblicato un saggio-proposta con lo scopo di avviare una discussione attorno al ciclo di sviluppo appena cominciato e che porterà alla fine al rilascio di Debian 8.0, nome in codice "Jessie". Si tratterebbe di un cambiamento drastico della filosofia che c´è dietro al branch "Testing", ovvero gli archivi che, una volta portato a zero il totale dei bug considerati critici dei pacchetti che contengono, vanno a costituire una nuova versione "Stable" di Debian.
Il problema identificato dai due hacker Debian è che, ancora una volta, il "freeze" di Wheezy (il periodo di tempo in cui è ammesso solo il rilascio di bugfix) è stato troppo lungo: 10 mesi. Un periodo di tempo che viene definito "frustrante per tutti", per gli sviluppatori a causa del tantissimo lavoro da fare, per i progetti in upstream, e per gli utenti, visto che le versioni dei software al momento del rilascio tendono ad essere già molto datate essendo rimaste letteralmente bloccate per così tanto tempo. La proposta è questa: mantenere il freeze più corto possibile, nell´ordine di 2 settimane e certamente non superiore a 2 mesi.
Ovviamente allo stato attuale non si può semplicemente accorciare il freeze senza abbassare di netto la qualità di Debian, e pertanto c´è da ripensare completamente il modo in cui Debian viene sviluppata. Il cambiamento fondamentale che viene proposto è quello di cominciare a mantenere Testing in uno stato il più vicino possibile ad una release, in ogni momento del ciclo di sviluppo.
Al momento le cose sono ben diverse: per definizione, al momento del rilascio Debian ha 0 bug bloccanti, ma non appena vengono riaperti i repository in seguito alla release, il conteggio va alle stelle e lo sviluppo prosegue fino al freeze. Solo allora si comincia a guardare a questo conteggio e cercare di azzerarlo, ma a quel punto il lavoro è mastodontico e porta a periodi di freeze lunghissimi. Come accorciarli così drasticamente allora?
Il primo passo è riconoscere l´importanza delle release: i due proponenti si rendono conto che dai tantissimi maintainer che fanno parte del progetto, non ci si può aspettare che tutti "diano la stessa importanza ad un rilascio ufficiale" rispetto al lavoro di sviluppo di per sè. Ma i rilasci sono importanti per il progetto, e dunque Debian deve cambiare per far sì che "il lavoro della minoranza che non pensa alle relase non sia d´ostacolo a realizzarne una".
La parte fondamentale di questo nuovo processo è però quella di mantenere Testing, in ogni momento, il più possibile libera da bug critici. Per farlo, Wirzenius e Allbery propongono nuove politiche di gestione di Testing che sono chiaramente votate a sviluppare una cultura "priva di bug critici" tra i tanti sviluppatori Debian. Vediamole:
- Rimuovere i pacchetti contenenti bug critici quanto prima: quando un bug critico viene identificato e confermato, rimuovere il pacchetto dagli archivi, anche in maniera automatica se necessario, compresi i pacchetti che dipendono da esso. Questo assicurerebbe un branch Testing sempre rilasciabile. I pacchetti possono essere re-immessi in Testing una volta scomparso il bug critico. Se il pacchetto è troppo importante per essere rimosso (per esempio bash, o gcc), dovrebbe diventare priorità per tutti. Questo può essere fatto in modi diversi, dal giocoso (uno dei bug fixing party di Debian, ma solo per quel bug) al dittatoriale (disabilitare tutti gli upload finché quel bug non viene sistemato).
- Quando i bug critici superano una certa soglia, dichiarare un mini-freeze: si tratta di un processo automatico che più di tutti aiuterebbe gli sviluppatori a "stare in riga". Verrebbero bloccati i passaggi di pacchetti da Unstable a Testing, tranne per quei pacchetti interessati dai bug critici. Una volta scesi sotto la soglia consentita, le porta dei repository verrebbero riaperte a tutti.
- Limitare il numero dei pacchetti considerati fondamentali per una release: Debian è troppo grande per dare la stessa importanza ad ogni pacchetto, e infatti questo non avviene. Esistono pacchetti senza cui non può esserci release, come bash, ma altri che possono essere rimossi con meno remore. La proposta vuole codificare questo comportamento, ovvero stabilire con certezza quali pacchetti classificare come necessari per una release. L´idea è quella di avere delle "installazioni di riferimento" per ogni caso d´uso (mail server, LAMP, desktop, ecc) ben calibrate e dall´ampio consenso, simili ai "task" che si vedono nell´installer, ma per le quali vengano scelti questi pacchetti indispensabili, secondo un approccio del tipo "se funzionano, possiamo rilasciare, se non funzionano no". Questo creerebbe pacchetti di serie A e di serie B, ma questo è inevitabile secondo i proponenti, visto che "semplicemente, nethack non è importante quanto bash". Ovviamente un pacchetto non incluso in una installazione di riferimento non verrà certo rimosso da Debian, ma semplicemente le release non potranno essere rinviate a causa sua.
Infine, i proponenti vorrebbero che Debian introducesse in modo estensivo i test automatici, facendoli diventare i protagonisti della migrazione dei pacchetti da unstable a testing. Non sono da intendere come sostituti dei bug report, ma come loro complemento. Per certe categorie di bug, come le regressioni, è molto più semplice identificarli attraverso un test automatico piuttosto che affidarsi ai report degli utenti. Si potrebbe fare in modo che questi test vengano eseguiti ogni tot upload, e in particolare contro le installazioni di riferimento prima citate.