Prima di tutto diamo un'occhiata al particolare caso della distribuzione Experimental: consiste in un gruppo di pacchetti Debian relativi a software in corso di sviluppo, e come dice il nome non necessariamente completato. Non tutto passa attraverso questa fase, alcuni sviluppatori scelgono di aggiungere i pacchetti in questa versione per ottenere un feedback dagli utenti più esperti (o coraggiosi).

In alternativa, questa distribuzione ospita spesso importanti modifiche ai pacchetti base, la cui integrazione con gravi bug nella versione Unstable avrebbe ripercussioni critiche. Si tratta, dunque, di una distribuzione completamente isolata, i suoi pacchetti non migreranno mai verso un'altra versione (se non per l'intervento esplicito del manutentore o dei ftpmaster).

Torniamo al caso di un pacchetto normale. Il manutentore crea un pacchetto iniziale, che compila per la versione Unstable e lo carica sul server ftp-master.debian.org. La prima operazione consiste in un esame e nella convalida da parte degli ftpmaster. Il software risulta disponibile nella distribuzione Unstable che è rischiosa, ma è una scelta degli utenti il preferire una versione più aggiornata che potrebbe presentare gravi bug ad una più testata e stabile. Scoprono il programma e lo provano.

Se incontrano bug, li segnalano al manutentore del pacchetto. Il manutentore prepara regolarmente versioni corrette, che rende disponibili sul server.

Ogni nuovo pacchetto aggiornato è mantenuto allineato su tutti i mirror di Debian sparsi per il mondo in meno di sei ore. Gli utenti provano le correzioni e cercano altri problemi che potrebbero essere stati causati dalle modifiche. Potrebbero susseguirsi rapidamente molti aggiornamenti. Durante questo periodo entrano in azione i robot autobuilder. Frequentemente il manutentore disponendo di un PC tradizionale ha compilato il suo pacchetto su una sola architettura i386 (oppure amd64); gli autobuilder provvedono automaticamente a compilare le versioni per tutte le altre. Alcune compilazioni potrebbero non andare a buon fine; il manutentore riceverà una segnalazione di bug nel quale vengono riportati gli errori riscontrati, che provvederà a correggere nelle versioni successive. Quando il bug viene scoperto da uno specialista dell'architettura in questione, alla segnalazione del bug potrebbe essere allegata una patch pronta all'uso.

Successivamente, il pacchetto sarà maturato; compilato in tutte le architetture, non avrà subito modifiche recenti. Diventa quindi candidato per l'inclusione nella distribuzione Testing: un gruppo di pacchetti della versione Unstable scelti in base ad alcuni criteri quantificabili. Automaticamente ogni giorno un programma seleziona i pacchetti da includere nella Testing, secondo elementi che garantiscono un certo livello di qualità:

Il sistema non è chiaramente infallibile; saltano fuori regolarmente bug critici nei pacchetti inclusi in Testing. Tuttavia, è generalmente efficace e Testing pone molti meno problemi rispetto a Unstable, risultando per molti utenti, un buon compromesso tra novità e stabilità.

Supponiamo che il nostro pacchetto sia ora incluso in Testing. Anche se ha margini di miglioramento, il manutentore deve continuare a migliorarlo e riavviare il processo dalla Unstable (ma la sua successiva inclusione nella Testing è generalmente più veloce: se non è cambiato in modo significativo, tutte le sue dipendenze sono già disponibili). Quando viene raggiunta la perfezione, il manutentore ha completato il proprio compito. La prossima fase è l'inclusione nella distribuzione Stable, che è in realtà una semplice copia della Testing del momento deciso dal Release Manager. Idealmente questa decisione viene presa quando l'installatore è pronto e quando nessun programma in Testing contiene qualche bug critico conosciuto.

Dato che un momento simile non si verifica mai in realtà, in pratica Debian deve fare un compromesso: saranno rimossi i pacchetti il cui manutentore non è riuscito a correggere in tempo i bug, o si accetta di rilasciare una distribuzione con alcuni bug nelle migliaia di programmi. Il Release Manager avrà già annunciato in precedenza un periodo di freeze (congelamento), durante il quale ogni aggiornamento di Testing deve essere approvato. L'obiettivo è quello di evitare qualsiasi nuova versione (con i suoi nuovi bug), e di approvare solo aggiornamenti che correggono i bug.

Dopo il rilascio di una nuova versione stabile, lo Stable Release Manager ne gestisce tutto l'ulteriore sviluppo (chiamate «revisioni», es: 5.0.1, 5.0.2, 5.0.3 per la versione 5.0). Questi aggiornamenti includono sistematicamente tutte le patch di sicurezza. Questi potranno anche includere correzioni più importanti (per poter includere aggiornamenti di un pacchetto, il manutentore deve dimostrare la gravità del problema che intende correggere).

Fine del viaggio: il nostro ipotetico pacchetto è ora incluso nella distribuzione Stable. Questo viaggio, non senza difficoltà, spiega il notevole tempo che separa due rilasci di Debian Stable. Ciò contribuisce, nel complesso, alla sua reputazione di qualità. Inoltre, la maggioranza degli utenti si accontenta di utilizzare una delle tre distribuzioni disponibili contemporaneamente. Gli amministratori di sistema, preoccupati soprattutto per la stabilità dei loro server, prendono in giro l'ultima versione di GNOME; possono scegliere Debian Stable e sono contenti. Gli utenti finali, più interessati alle ultime versioni di GNOME o KDE piuttosto che ad un sistema stabile e solido come una roccia, sceglieranno Debian Testing per avere un buon compromesso tra la mancanza di gravi problemi e un software abbastanza aggiornato. Infine, gli sviluppatori e gli utenti più esperti possono tracciare il sentiero, testando tutti gli ultimi sviluppi in Debian Unstable con il rischio di soffrire qualche mal di testa per i bug che saltano fuori ad ogni nuova versione di un programma. Ad ognuno la sua Debian.