Product SiteDocumentation Site

1.6. Ciclo di vita di un rilascio

Il progetto manterrà contemporaneamente tre o quattro differenti versioni dello stesso programma, definite Experimental(Sperimentale), Unstable(Instabile), Testing(in test) e Stable(Stabile), Oldstable,ed anche Oldoldstable. Ognuna corrisponde ad una differente fase dello sviluppo. Per capire meglio, diamo un'occhiata al percorso di un programma, dal primo impacchettamento, all'inclusione in una versione stabile di Debian.

1.6.1. Lo stato Experimental (sperimentale)

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 deglii ftpmaster). Inoltre non è autosufficiente: solo un sottoinsieme dei pacchetti esistenti sono presenti nella versione Experimental, e generalmente non include il sistema di base. Questa distribuzione è quindi particolarmente utile in combinazione con un'altra distribuzione, indipendente, come Unstable.

1.6.2. Lo stato Unstable (instabile)

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 è la "punta di diamante" delle distribuzioni scelte dagli utenti che sono più preoccuapti di avere pacchetti aggiornati che preoccupati per i gravi bug. Scoprono il programma e poi lo testano.
Se incontrano bug, li segnalano al manutentore del pacchetto. Il manutentore prepara regolarmente versioni corrette, che rende disponibili sul server.
Ogni nuovo pacchetto aggiornato è aggiornato 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. Spesso, il manutentore dispone di un PC tradizionale ed ha compilato il suo pacchetto sull' architettura amd64 (oppure i386); gli autobuilder provvedono automaticamente a compilare le versioni per tutte le altre architetture. 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.
Compilazione di un pacchetto con autobuilder

Figura 1.2. Compilazione di un pacchetto con autobuilder

1.6.3. Migrazione alla Testing (in prova)

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à:
  1. mancanza di bug critici, o almeno inferiori rispetto a quelli presenti nella versione attualmente inclusa in Testing;
  2. trascorsi almeno 10 giorni in Unstable, che dovrebbe essere un tempo sufficiente per trovare e segnalare eventuali problemi gravi;
  3. compilazione riuscita su tutte le architetture ufficialmente supportate;
  4. tutte le dipendenze possono essere soddisfatte in Testing o possono almeno esservi trasferite insieme al pacchetto in questione.
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à.

1.6.4. La promozione da Testing a Stable

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 è stato cambiato in modo significativo, tutte le sue dipendenze sono già disponibili). Quando raggiunge la perfezione, il manutentore ha completato il proprio lavoro. La fase successiva è l'inclusione nella distribuzione Stable, che è in realtà una semplice copia della Testing al momento deciso dal Release Manager. Idealmente questa decisione viene presa quando il programma di installazione è pronto, e quando nessun programma in Testing contiene alcun 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.
Il percorso di un pacchetto attraverso le varie versioni di Debian

Figura 1.3. Il percorso di un pacchetto attraverso le varie versioni di Debian

Dopo il rilascio di una nuova versione stabile, lo Stable Release Manager ne gestisce tutto l'ulteriore sviluppo (chiamate «revisioni», es: 7.1, 7.2, 7.3 per la versione 7). 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 percorso, il nostro ipotetico pacchetto viene incluso nella distribuzione Stable. Questo percorso, 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 maggior parte 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!
Percorso cronologico di un programma impacchettato da Debian

Figura 1.4. Percorso cronologico di un programma impacchettato da Debian

1.6.5. Stato di Oldstable e Oldoldstable

Ogni rilascio Stable ha una durata prevista di circa 5 anni e dato che i rilasci tendono ad avvenire ogni 2 anni, ci possono essere fino a 3 rilasci che devono essere supportati in un determinato momento. Quando viene rilasciata una nuova versione stabile, il precedente rilascio diventa Oldstable e quello ancora prima diventa Oldoldstable.
Questo Supporto a Lungo Termine (LTS) dei rilasci di Debian è un'iniziativa recente: singoli collaboratori e aziende hanno unito le forze per creare il gruppo LTS di Debian. I rilasci più vecchi che non sono più supportati dal team di sicurezza di Debian sono sotto la responsabilità di questo nuovo team.
Il team di sicurezza di Debian gestisce il supporto di sicurezza sull'attuale versione Stable ed anche sulla versione Oldstable (ma solo per il tempo strettamente necessario per garantire un anno di sovrapposizione con l'attuale versione stabile). Ciò equivale grosso modo a tre anni di supporto per ogni versione. The team LTS di Debian si occupa degli ultimi (due) anni di supporto di sicurezza in modo che ogni rilascio benefici di almeno 5 anni di assistenza e che gli utenti possano effetuare l'aggiornamento dalla versione N alla N+2.