Product SiteDocumentation Site

1.6. Cycle de vie d'une release

Le projet dispose à tout instant de trois ou quatre versions différentes de chaque logiciel, nommées Experimental, Unstable, Testing et Stable. Chacune correspond à un stade différent du développement. Pour bien les comprendre, suivons le parcours d'un programme, de sa première mise en paquet à son intégration dans une version stable de Debian.

1.6.1. Le statut Experimental

Traitons d'abord le cas particulier de la distribution Experimental : c'est un ensemble de paquets Debian correspondant à des logiciels en cours de développement et pas forcément finalisés — d'où son nom. Tout ne transite pas par cette étape ; certains développeurs y créent des paquets pour obtenir un premier retour des utilisateurs les plus expérimentés (ou les plus courageux).
D'autre part, cette distribution abrite fréquemment des modifications importantes portant sur des paquets de base et dont l'intégration dans Unstable avec des bogues gênants aurait des répercussions trop importantes et bloquantes. C'est donc une distribution totalement isolée, dont les paquets ne migrent jamais vers une autre (sauf intervention expresse du mainteneur ou des ftpmasters). Elle n'est également pas utilisable de manière indépendante : seul un sous-ensemble des paquets existants est présent dans Experimental et elle ne contient généralement pas le système de base. Cette distribution est donc exploitable seulement en combinaison avec une autre distribution indépendante, comme Unstable.

1.6.2. Le statut Unstable

Revenons au cas d'un paquet type. Le mainteneur crée un premier paquet, qu'il compile pour Unstable et place sur le serveur ftp-master.debian.org. Cette première manifestation implique inspection et validation par les ftpmasters. Le logiciel est alors disponible dans Unstable, la distribution la plus à jour choisie par des utilisateurs préférant le dernier cri à l'assurance de l'absence de bogues graves. Ceux-ci découvrent alors le programme et le testent.
S'ils y découvrent des bogues, ils les décrivent à son mainteneur. Ce dernier prépare alors régulièrement des versions corrigées, qu'il place sur le serveur.
Toute nouvelle mise en ligne est répercutée sur tous les miroirs Debian du monde dans les 6 heures. Les utilisateurs valident alors la correction et cherchent d'autres problèmes, consécutifs aux modifications. Plusieurs mises à jour peuvent ainsi s'enchaîner rapidement. Pendant ce temps, les robots autobuilders sont entrés en action. Le plus souvent, le mainteneur ne dispose que d'un PC traditionnel et aura compilé son paquet pour architecture amd64 (ou i386) ; les autobuilders ont donc pris le relais et compilé automatiquement des versions pour toutes les autres architectures. Certaines compilations pourront échouer ; le mainteneur recevra alors un rapport de bogue signalant le problème, à corriger dans les prochaines versions. Lorsque le bogue est découvert par un spécialiste de l'architecture concernée, il arrive que ce rapport soit accompagné d'un correctif prêt à l'emploi.
Compilation d'un paquet par les autobuilders

Figure 1.2. Compilation d'un paquet par les autobuilders

1.6.3. La migration vers Testing

Un peu plus tard, le paquet aura mûri ; compilé sur toutes les architectures, il n'aura pas connu de modifications récentes. C'est alors un candidat pour l'intégration dans la distribution Testing — ensemble de paquets Unstable sélectionnés sur quelques critères quantifiables. Chaque jour, un programme choisit automatiquement les paquets à intégrer à Testing, selon des éléments garantissant une certaine qualité :
  1. absence de bogues critiques, ou tout du moins nombre inférieur à celui de la version actuellement intégrée dans Testing ;
  2. villégiature minimale de 10 jours dans Unstable, ce qui laisse assez de temps pour trouver et signaler les problèmes graves ;
  3. compilation réussie sur toutes les architectures officiellement prises en charge ;
  4. dépendances pouvant toutes être satisfaites dans Testing, ou qui peuvent du moins y progresser de concert avec le paquet.
Ce système n'est évidemment pas infaillible ; on trouve régulièrement des bogues critiques dans un paquet intégré à Testing. Il est pourtant globalement efficace et Testing pose beaucoup moins de problèmes qu'Unstable, représentant pour beaucoup un bon compromis entre la stabilité et la soif de nouveauté.

1.6.4. La promotion de Testing en Stable

Supposons notre paquet désormais intégré à Testing. Tant qu'il est perfectible, son responsable doit persister à l'améliorer et recommencer le processus depuis Unstable (mais ces inclusions ultérieures dans Testing sont en général plus rapides : à moins d'avoir changé de manière significative, toutes les dépendances sont déjà présentes). Quand il atteint la perfection, son mainteneur a fini son travail et la prochaine étape est l'inclusion dans la distribution Stable, en réalité une simple copie de Testing à un moment choisi par le Release Manager. L'idéal est de prendre cette décision quand l'installateur est prêt et quand plus aucun programme de Testing n'a de bogue critique répertorié.
Étant donné que ce moment ne survient jamais dans la pratique, Debian doit faire des compromis : supprimer des paquets dont le mainteneur n'a pas réussi à corriger les bogues à temps ou accepter de livrer une distribution comptant quelques bogues pour des milliers de logiciels. Le Release Manager aura préalablement prononcé une période de freeze (gel), où il devra approuver chaque mise à jour de Testing. Le but est d'empêcher toute nouvelle version (et ses nouveaux bogues) et de n'approuver que des mises à jours correctives.
Parcours d'un paquet au sein des différentes versions de Debian

Figure 1.3. Parcours d'un paquet au sein des différentes versions de Debian

Après la sortie de la nouvelle version stable, le Stable Release Manager en gère les évolutions ultérieures (appelées « révisions ». ex : 5.0.1, 5.0.2, 5.0.3 pour la version 5.0). Ces mises à jour intègrent systématiquement tous les correctifs de sécurité. On y trouve également les corrections les plus importantes (le mainteneur du paquet doit prouver la gravité du problème qu'il souhaite corriger pour faire intégrer sa mise à jour).
À la fin du voyage, notre hypothétique paquet est désormais intégré à la distribution stable. Ce trajet, non dépourvu de difficultés, explique les délais importants séparant les versions stables de Debian. Il contribue surtout à sa réputation de qualité. De plus, la majorité des utilisateurs est satisfaite par l'emploi de l'une des trois distributions disponibles en parallèle. Les administrateurs système, soucieux avant tout de la stabilité de leurs serveurs, se moquent de la dernière version de GNOME ; ils opteront pour Debian Stable et en seront satisfaits. Les utilisateurs finaux, plus intéressés par la dernière version de GNOME ou de KDE que par une stabilité irréprochable, trouveront en Debian Testing un bon compromis entre absence de problèmes graves et logiciels relativement à jour. Enfin, les développeurs et utilisateurs les plus expérimentés pourront ouvrir la voie en testant toutes les nouveautés de Debian Unstable dès leur sortie, au risque de subir les affres et bogues inhérents à toute nouvelle version de logiciel. À chaque public sa Debian !
Parcours chronologique d'un paquet logiciel empaqueté par Debian

Figure 1.4. Parcours chronologique d'un paquet logiciel empaqueté par Debian