Ubuntu logo

Packaging Guide

1. Introduction au Développement d’Ubuntu

Ubuntu est constitué de milliers de composants différents, écrits dans de multiples langages de programmation. Chaque composant - pouvant être une bibliothèque logicielle, un outil ou une application graphique - est disponible sous forme d’un paquet source. Dans la plupart des cas, les paquets sources se composent de deux parties : le code source réel et les métadonnées. Ces dernières comprennent les dépendances du paquet, les droits d’auteur et les informations de licence, ainsi que des instructions sur la façon de construire le paquet. Une fois ce paquet source compilé, le processus de construction fournit les paquets binaires, en d’autres termes, les fichiers .deb que les utilisateurs peuvent installer.

Every time a new version of an application is released, or when someone makes a change to the source code that goes into Ubuntu, the source package must be uploaded to Launchpad’s build machines to be compiled. The resulting binary packages then are distributed to the archive and its mirrors in different countries. The URLs in /etc/apt/sources.list point to an archive or mirror. Every day images are built for a selection of different Ubuntu flavours. They can be used in various circumstances. There are images you can put on a USB key, you can burn them on DVDs, you can use netboot images and there are images suitable for your phone and tablet. Ubuntu Desktop, Ubuntu Server, Kubuntu and others specify a list of required packages that get on the image. These images are then used for installation tests and provide the feedback for further release planning.

Le développement d’Ubuntu est très dépendant de la phase actuelle du cycle de sortie. Nous publions une nouvelle version d’Ubuntu tous les six mois, ce qui est rendu possible par l’établissement dates strictement figées. À chaque échéance atteinte, les développeurs doivent faire moins de modifications, ou les moins intrusives possibles. Le gel des fonctionnalités est la première grosse échéance après la première moitié du cycle. À ce stade, les nouvelles fonctionnalités doivent être largement appliquées. Le reste du cycle est censé se concentrer sur la correction des bogues. Ensuite, l’interface utilisateur, puis la documentation, le noyau, etc. sont gelés, puis la version bêta est mise en ligne pour recevoir un maximum de tests. À partir de la version bêta, seuls les bogues critiques sont corrigés, une version candidate est créée et lorsqu’elle ne contient pas de problèmes graves, elle devient la version finale.

./_images/cycle-items.png

Des milliers de paquets sources, des milliards de lignes de code, des centaines de contributeurs exigent beaucoup de communication et de planification pour maintenir des normes élevées de qualité. Au début et au milieu de chaque cycle de version, nous avons le Sommet des Développeurs Ubuntu, où les développeurs et les contributeurs sont réunis pour planifier les fonctionnalités des prochaines versions. Chaque fonctionnalité est décrite par ses intervenants et un cahier des charges est écrit, contenant des informations détaillées sur ses hypothèses, sa mise en œuvre, les modifications nécessaires à d’autres endroits, la façon de la tester, etc. Tout cela est fait de manière ouverte et transparente, afin que vous puissiez participer à distance et regarder un flux vidéo, discuter avec les participants et adhérer aux modifications de spécifications, de sorte que vous soyez toujours informé.

Chaque modification ne peut malgré tout pas être abordée lors d’une réunion, en particulier parce qu’Ubuntu repose sur des modifications effectuées dans d’autres projets. C’est pourquoi les contributeurs à Ubuntu restent constamment en contact. La plupart des équipes ou des projets utilisent des listes de diffusion dédiées en vue d’éviter trop de perturbations inutiles. Pour la coordination plus immédiate, les développeurs et les contributeurs utilisent Internet Relay Chat (IRC). Toutes les discussions y sont ouvertes et publiques.

Un autre outil important en matière de communication est le rapport de bogue. Chaque fois qu’un défaut est décelé dans un paquet ou une partie de l’infrastructure, un rapport de bogue est déposé dans Launchpad. Toutes les informations sont recueillies dans ce rapport et l’importance, le statut et l’affectation du bogue sont mis à jour si nécessaire. Cela en fait un outil efficace pour surmonter les bogues dans un paquet ou un projet et pour organiser la charge de travail.

La plupart des logiciels disponibles dans Ubuntu ne sont pas écrits par les développeurs d’Ubuntu eux-mêmes. Une grande partie est écrite par les développeurs d’autres projets Open Source et ensuite intégrés dans Ubuntu. Ces projets sont appelés “amonts”, parce que leurs codes sources se déversent dans Ubuntu, où nous faisons “juste” leur intégration. La relation avec les projets en amonts est extrêmement importante pour Ubuntu. Ce n’est pas uniquement le code qu’Ubuntu reçoit des projets en amont, ceux-ci profitent également des utilisateurs, des rapports de bogues et des correctifs de la part d’Ubuntu (et des autres distributions).

L’amont le plus important pour Ubuntu est Debian. Debian est la distribution sur laquelle Ubuntu est basée et la plupart des décisions de conception relatives à l’infrastructure d’empaquetage sont prises là. Traditionnellement, Debian a toujours eu des responsables dédiés pour chaque paquet ou des équipes de maintenance dédiées. Dans Ubuntu, ce sont également des équipes qui s’intéressent à un sous-ensemble de paquets et, naturellement, chaque développeur possède un domaine d’expertise, mais la participation (et les droits de téléchargement) est généralement ouverte à tous ceux qui prouvent leur talent et leur volonté.

Obtenir une modification dans Ubuntu en tant que nouveau collaborateur n’est pas aussi intimidant qu’il n’y paraît et peut même s’avérer une expérience très enrichissante. Il ne s’agit pas seulement d’apprendre quelque chose de nouveau et d’excitant, mais également de partager une solution et de résoudre un problème pour des millions d’utilisateurs.

Le développement Open Source intervient dans un monde partagé selon différents objectifs et différents domaines d’intérêt. Par exemple, cela pourrait être le cas d’un Amont particulier intéressé par le travail sur une nouvelle fonctionnalité importante, alors qu’Ubuntu, en raison de son échéancier serré de sortie, est intéressé par la fourniture d’une version robuste avec juste quelques corrections supplémentaires de bogues. C’est pourquoi nous utilisons le “Développement Distribué”, où le code est en cours d’élaboration dans différentes branches qui sont fusionnées les unes avec les autres, après des révisions du code et des discussions adéquates.

./_images/cycle-branching.png

Dans l’exemple mentionné ci-dessus, il serait logique de fournir Ubuntu avec la version existante du projet, d’ajouter le correctif, de l’inclure à l’amont pour leur prochaine version et de fournir de nouveau le projet (s’il est convenable) avec la prochaine version d’Ubuntu. Ce serait le meilleur compromis possible et une situation gagnant-gagnant.

Pour corriger un bogue dans Ubuntu, vous devrez d’abord obtenir le code source pour le paquet, puis travailler sur le correctif, le documenter pour qu’il soit simple à comprendre pour les autres développeurs et utilisateurs, puis construire le paquet pour le tester. Après l’avoir testé, vous pouvez aisément proposer que la modification soit incluse dans la version d’Ubuntu actuellement en développement. Un développeur ayant les droits de téléchargement l’examinera pour vous puis l’intégrera dans Ubuntu.

./_images/cycle-process.png

En cherchant une solution, il est généralement intelligent de vérifier avec l’amont et de voir si le problème (ou une solution possible) est connu et, dans le cas contraire, de faire de votre mieux pour que la solution soit un effort concerté.

Des étapes supplémentaires pourraient induire le rétroportage des modifications vers une ancienne version d’Ubuntu encore prise en charge et leur transmission vers l’amont.

Les pré-requis les plus importants pour réussir dans le développement d’Ubuntu sont les suivants : avoir un talent pour “faire que les choses fonctionnent de nouveau”, ne pas avoir peur de lire la documentation et de poser des questions, jouer collectif et apprécier le travail de détective.

Good places to ask your questions are ubuntu-motu@lists.ubuntu.com and #ubuntu-motu on freenode.. You will easily find a lot of new friends and people with the same passion that you have: making the world a better place by making better Open Source software.