En préparation depuis plusieurs jours, je me décide enfin à publier. Ce résumé décrit de façon synthétique (mais quand même assez longue :)) le développement d'une version d'Ubuntu, entre la conception et la sortie finale. Bonne lecture ! :)

Introduction : Qu'est qu'Ubuntu ?
Question bête peut être, mais je préfère clarifier les choses dès le début. Ubuntu n'est pas un programme comme les autres. C'est un ensemble de programmes qui doivent fonctionner ensembles et en harmonie. En clair, le principal travail des développeurs, est de faire cohabiter tout ça, d'adapter les programmes le cas échéant. Éventuellement, certains vont développer des morceaux de programmes pour palier des manques. Cette description est centré sur Ubuntu, mais peut en partie s'adapter à toutes les distributions GNU/Linux.

La particularité d'Ubuntu, est de ne pas partir de zéro : elle s'appuie sur le travail de Debian. En effet, comme nous le verrons plus loin, sa base de travail, c'est les programmes provenant de Debian, que Ubuntu modifie à sa sauce, ajoute des améliorations etc ...

Alors premières questions que vous devez vous poser, pourquoi « voler » le travail de Debian ? Est-ce vraiment légal / moral ? Pourquoi ne pas travailler directement avec Debian ? D'abord, il faut savoir que la pratique est courante, de nombreuses distributions sont dérivées de Debian (Xandros, Knoppix, Linspire etc ...) . Il faut savoir aussi que Debian possède 3 branches principales : stable, testing, unstable (il existe une branche expérimentale, qui n'est absolument pas conseillée d'utiliser). Mais pour être considéré comme stable, un paquet doit avoir été testé énormément, et il faut pas mal de temps pour arriver à ce stade de stable. L'avantage est que les logiciels sont ultra-testés et seront d'une grande stabilité. Cependant, la contrepartie est que ces programmes seront plutôt anciens, et donc sans toutes les fonctionnalités. D'ailleurs, cette branche stable est conseillé principalement pour une utilisation serveur, ou la stabilité et la sécurité doivent être irréprochables. Pour une utilisation bureautique, on se tournera + vers la branche testing, sachant que les paquets testing ont déjà été bien mis à l'épreuve et sont candidats pour passer en stable si après un certains temps on ne découvre pas de bugs bloquants.

Mark Shuttleworth, le créateur d'Ubuntu (et développeur Debian) a voulu tenter une aventure. Trouvant que les sorties de Debian étaient trop longues, il a voulu mettre à disposition des utilisateurs des programmes Debian récents, mais utilisables (c'est à dire sans trop de bugs). Il décida alors de stabiliser la branche unstable de Debian pour la rentre utilisable. Et cela est toujours vrai aujourd'hui. C'est pour cela qu'Ubuntu dérive de Debian ; en fait, il dérive de la branche unstable de Debian. C'est donc une sorte de Debian unstable + des extras. Voilà pourquoi il était impossible de collaborer directement avec le projet Debian, car il n'aurait jamais acceptés de sortir une distribution unstable. Cependant le travail d'Ubuntu n'est pas tout à fait perdu, car certains patchs d'Ubuntu remonte vers Debian unstable (pas tous, mais c'est une autre histoire :)).

Dernier point avant de continuer, je vais vous parler brièvement de Launchpad. Pour ceux qui ne le savent pas encore, Launchpad est le site qui coordonne le développement d'Ubuntu et de tout programme qui s'y affile. C'est une sorte de Sourceforge ou tous les projets interagissent entre eux. Il intègre un gestionnaire de bugs (Malone), de traduction (Rosetta), d'améliorations ou features (Blueprints), un système de contrôle de code « bazar » (similaire à SVN ou CVS) (Soyuz) ... C'est l'endroit à connaître quant on veut développer ou tester Ubuntu. On en reparlera pendant le développement. Une précision tout de même, Launchpad n'est pas un logiciel libre. La position actuelle de Canonical est qu'ils ne souhaitent pas que d'autres Launchpad voient le jour autre part, car son but est principalement d'être unique, de centraliser les informations. (Là aussi c'est un autre débat :))

Voilà pour ces rappels historiques et techniques.

l'Annonce
C'est la tradition, le développement commence un peu avant la sortie de la version précédente, par une annonce officielle de Mark Shuttleworth. Dans cette lettre à tous les développeurs (et utilisateurs), il donne les grandes orientations qu'il souhaiterait donner à la prochaine version, avec les futurs améliorations et les principaux axes de travail. Cela ne veut pas dire que tout ce qui est annoncé sera dans la prochaine version, la décision finale venant en fait du comité technique, et non de Mark. Enfin, un nom d'animal est donné, suivant les lettres de l'alphabet (Dapper Drake, Edgy Eft, Feisty Fawn, Gutsy Gibbon ...).

les Spécifications
Comme tout bon projet informatique qui se respecte, il faut commencer par les spécifications, cet ensemble d'idées avec les moyens d'y arriver. Ces spécifications peuvent être proposées par des développeurs, ou de simples utilisateurs. Écrire une bonne spec, ce n'est pas seulement avoir une bonne idée et la balancer comme ça. Il y a un format qui existe, avec notamment les paquets affectés par cette specs, les améliorations précises, les utilisations possibles avec des exemples concrets, les problèmes qui vont être rencontrés etc ... De plus, une spec n'a d'intérêts que si elle est réalisable, donc il faut qu'elle soit techniquement faisable et qu'un développeur travaille dessus.

Une fois écrite (sur le wiki) et enregistrée dans Blueprint, ces spécifications vont être discutées. Outre la possibilité technique, ces spécifications sont classées selon leur importance par les responsables d'Ubuntu. Cela dépends uniquement de la politique d'Ubuntu et des priorités de la prochaine sortie.

Ces discussions sur les spécifications se passent d'abord via le site, mais aussi pendant les « Summit », ces réunions ou les principaux développeurs se rencontrent pour discuter des principales spécifications. Cela marque aussi le début « symbolique » du développement de la nouvelle version.

A la fin de ce processus, plusieurs spécifications sont choisies. Elles constitueront la roadmap officielle de cette nouvelle version. Leurs statuts va alors changer avec leur évolution, de « Unknow» ou « Started » à « Implement ». Cependant, cette roadmap est plus une direction qu'un but. D'ailleurs, il arrive que des spécifications soient repoussées, non implémentées, oubliées ... donc, ne pas se fier aveuglément aux spécifications.

la Merge
Comme nous l'avons vu, Ubuntu dérive de la branche unstable de Debian. Mais ces 2 projets évoluent à leurs rythmes. Avant chaque début de développement, Ubuntu a besoin de se resynchroniser avec les paquets Debian unstable. Donc pendant près d'un mois, les paquets de la branche Debian unstable vont être importés et réempaquetés à la sauce Ubuntu. Cet import est fait en parti par un outil qui s'appelle Merge O Matic (proprio aussi et développé par Canonical, mais une alternative libre existe) qui fait tout le travail de merge (export des dépôts Debian, réempaquetage, mise à jour du changelog, import dans les dépôts d'Ubuntu). Le reste est fait à la « main ». Ce travail de synchronisation avec Debian va se poursuivirent jusqu'à la fin du développement. Cependant, plus on se rapproche de la sortie, plus les conditions pour de tels intégrations sont draconiennes. D'ailleurs, les développeurs ont plutôt tendance à intégrer des patchs Debian plutôt que le paquet en entier.

Une fois les spécifications et la merge bien entamées, le travail de développement peut commencer. Les développeurs vont alors choisir des programmes ne se trouvant pas dans Debian et les récupérer pour en faire des paquets. Il arrive aussi qu'il n'y ai que des patchs qui soient appliqués. C'est aussi pendant cette période que les développements d'améliorations et de fonctionnalités en plus sont effectués. Ils sont intégrés au fur et à mesure de leur avancement.

CD de Test
Durant le développement, des CD de tests sont produits. Les paquets sont alors gelés pendant quelques heures (voir quelques jours) et on procède aux tests de création de l'iso. Ces iso sont aussi prévus pour les testeurs, pour ne pas à avoir à télécharger tous les paquets et tester l'installation. Cependant, ce ne sont que des images de l'état des paquets à un instant T, donc avoir un système à jour revient au même. De même, il existe des fichiers iso quotidiens, là aussi des images à un instant T de l'état des paquets. Lorsque que l'on se rapproche de la sortie, ces tests d'iso sont plus importants.
Il existe 6 ou 7 CD Alpha qui ont des noms relatifs a l'appellation de la distribution. Une beta est disponible pour chaque distribution environ 1 mois avant la sortie officielle, et une Release Candidate 1 semaine avant la sortie officielle.

Stabilisation et gestion des bugs
Il n'y a pas vraiment de phase de stabilisation à proprement parlé. Les sorties étant tous les 6 mois, la correction des bugs se fait au fur et à mesure. Cependant, il y en a très peu pendant la merge avec Debian (ou alors seulement les plus bloquants ou flagrants). A l'inverse, les derniers jours avant la sortie sont consacrés à cette correction, et notamment des plus critiques.
Comme nous l'avons vu avant, la gestion des bugs est pris en charge par Malone. Sans entrer dans les détails (je le ferais sûrement dans un prochain billet), on peut dire que Malone centralise tous les bugs pour tous les paquets Ubuntu, qu'il soit rapportés manuellement ou automatiquement par apport. Une fois dans le système, des contributeurs vont les classer par criticité (Critical, High, Medium, Low, Wishlist) et par leurs états d'avancement (non confirmé, besoin d'infos, fixe en cours ...). Si ce n'est pas fait, il sera rattaché à un ou des paquets. Si le problème est situé en amont (c'est à dire lié au programme source et pas spécifiquement à son intégration à Ubuntu), un lien vers le bugtracker de ce programme est créé au niveau du bug dans Malone. Après, les développeurs dialoguent avec les utilisateurs/testeurs pour essayer de déterminer la cause exacte et les informe de l'avancement de l'éventuelle correction.
C'est grâce à cet outil que l'on suit la stabilisation d'Ubuntu. Les forums ne sont quasiment pas utilisés. Si vous voulez vraiment aider dans la correction des bugs, c'est dans launchpad qu'il faut aller voir ;)

Traductions
Parallèlement, la traduction des programmes est effectuée pour tous les paquets. Pour cela, on utilise Rosetta, le module de traduction de Launchpad. Chaque élément de texte est présenté dans sa langue d'origine, puis un champ est disponible en dessous pour traduire la phrase(ou « string »). On peut suivre l'évolution avec un pourcentage de traduction pour chaque langue. Le problème, c'est que les traductions « faciles » sont prises rapidement, et il finit pas rester que les éléments très techniques ou très spécifiques, difficile à traduire si on ne connaît pas le contexte.

Cycle de développement
Avant la sortie finale, la distribution passe plusieurs étapes avant d'arriver à la sortie officielle (ou Freeze). Il y a d'abord la feature freeze qui marque la fin d'améliorations significatives dans la distribution. Elle intervient 2 mois environ avant la sortie et marque normalement le départ de la chasse intensive aux bugs. En pratique, ce n'est pas aussi strict et des améliorations peuvent intervenir jusqu'à la beta. 2 semaines plus tard, c'est le blocage de toute demande de nouveaux paquets dans Universe. 1 mois avant la sortie offcielle, c'est la beta freeze, préparant la sortie de la beta une semaine plus tard. La distribution est alors jugée testable sans trop de risque et par le plus grand nombre de personne. Cela ne veut pas dire qu'elle est utilisable, mais en pratique les bétas sont déjà assez stables. Viendra enfin la sortie de la Release Candidate une semaine avant la sortie finale, puis la release offcielle. Ces détails ne sont qu'indicatifs, mais souvent assez bien respectés, seule la Dapper a eu presque 2 mois de retard. Cependant, les développeurs sont un peu plus souples sur l'intégration de paquets/nouveautés tardives (après la feature freeze). D'ailleurs, Gnome qui sort 1 mois avant chaque release d'Ubuntu est systématique intégré, mais c'est un cas spécial :) Mais le calendrier permet de bien se situer dans le développement d'Ubuntu.

Voilà pour une vue très générale (et un peu anarchique) du développement d'Ubuntu. De quoi suivre la prochaine sortie avec (j'espère :)) un regard différent. Pour vous faire une idée, on est actuellement (24/05) dans la phase de finalisation des specs, en plein développement :)

Liens utiles :