Full Circle Magazine would like to thank all those who emailed in questions about the development of Ubuntu. We tried to use as many questions as possible, merging those which were similar, and adding those we thought relevant.
Huge thanks go to both Alan Pope, for putting us in touch with Didier Roche, and to Didier for taking the time to answer all of our questions.
Like any good story, let’s start at the beginning…
Full Circle Magazine voudrait remercier tous ceux qui nous ont envoyé par mail leurs questions portant sur le développement d’Ubuntu. Nous avons tenté d’en reprendre autant que possible en fusionnant celles qui nous semblaient similaires et en ajoutant celles que nous pensions pertinentes.
Un grand merci à Alan Pope pour nous avoir mis en relation avec Didier Roche, et merci à Didier pour avoir pris le temps de répondre à nos questions.
Comme toutes les bonnes histoires, commençons donc par le début…
DESIGN
Q How much of a say does Canonical (and the community) have in Ubuntu, and how do you decide what features will be added to the next Ubuntu?
A Both questions seem to be linked to me. Basically, developers are free to decide and scratch their own itch on what they think is good for Ubuntu. Of course, for the core user experience, we are requesting the design team's feedback, and we try to align our goals with the main ones, like, in the past few iterations, going to a daily usable Ubuntu image or having an easier process for people making upstream development in Canonical to deliver on the platform.
In addition to that, we all have little pet projects dear to our hearts, and we try to do them as time permits. An example for me is OneConf, which I couldn’t push as far as I wanted, but I guess it’s still a working and nice feature for our users. We don’t do them because of x or y, we just do them because we think it’s good for Ubuntu. I guess before UDS (Ubuntu Developer Summit), we are all browsing forums, looking for ideas on brainstorm or similar website (or just talking to our LOCO) to gather feedback and see what we can add/enhance.
CONCEPTION
Q Dans quelle mesure Canonical (et la communauté) a-t-elle droit au chapitre dans Ubuntu, et comment décidez-vous quelles fonctionnalités seront ajoutées au prochain Ubuntu ?
R Les deux questions me semblent liées. Fondamentalement, les développeurs sont libres de se gratter les méninges sur ce qu’ils pensent bon pour Ubuntu. Bien entendu, pour l’expérience utilisateur de base, nous sollicitons les commentaires des équipes de conception et nous tentons d’aligner nos objectifs sur les plus importants, comme pour les quelques dernières itérations, afin d’obtenir une image Ubuntu utilisable au quotidien ou de simplifier le processus de livraison sur la plate-forme pour les gens développant en amont de Canonical.
A côté de cela, nous avons tous nos petits dadas personnels auxquels nous tenons et nous tentons de les faire avancer si nous en avons le temps. Un exemple, en ce qui me concerne, est OneConf, que je n’ai pas pu pousser aussi loin que je le souhaitais, mais je suppose que cette fonctionnalité est toujours opérationnelle et utile pour nos utilisateurs. Nous ne les mettons pas en oeuvre parce que x ou y le demande, nous les faisons parce que nous les pensons bonnes pour Ubuntu. Je suppose qu’avant l’UDS (Ubuntu Developer Summit), nous parcourons tous les forums à la recherche d’idées dans le remue-méninges, ou des sites internet de ce genre (ou simplement en parlant à nos LOCO) pour recueillir des commentaires et voir ce que nous pouvons ajouter/améliorer.
Q How do you decide what applications will be included/excluded from Ubuntu?
A Those discussion arise at UDS, where everyone can participate by coming (it’s a free and open event) or remotely. We try to start the discussion first on mailing lists, like the Ubuntu-desktop one (https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop) to focus those passionnate discussions.
Q Comment choisissez-vous les applications qui seront à inclure/exclure d’Ubuntu ?
R Ces discussions sont mises sur la table lors des UDS auxquels tout le monde peut participer en venant (c’est une manifestation libre et gratuite) ou à distance. Nous tentons d’abord d’amorcer la discussion via des diffusions selon des listes de messagerie, comme celle d’Ubuntu-desktop (https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop) de manière à axer ces débats passionnés.
Q How much of Ubuntu is Debian, and what do you change?
A Lucas Nussbaum gave, a couple of years ago, a talk with some stats about this. I encourage you to read his insightful slides posted on http://www.lucas-nussbaum.net/blog/?p=444. The figures shouldn’t have changed much, and I would say that we still have ~70% of packages untouched, directly imported from Debian, 15% of patched software compared to Debian to work with our toolchain and different set of dependencies (most of the times newer), and the rest is specific Ubuntu packages from our upstream and versions where we want to be ahead of Debian and pulled directly from them.
We have two main kind of differences: • The user experience is focused, especially for Ubuntu (not speaking for different flavors, like Kubuntu, Lubuntu… here), and we have to make drastic choices to get to where we want the user experience to be, even if this means diverging and modifying upstream components – this is the beauty of free software: if it doesn’t fit your need, you can change it slightly. • We also experiment with some advanced base support, like new stricter flags for the compiler, replacing bash by dash, adding some multi-arch support. Those kinds of advanced in-phase changes (taking a lot of time to have the whole set of packages in the archive working with them) are generally taken back in Debian. So Ubuntu endures the pain to do those transitions and Debian benefits from it.
Q Quelle est la part de Debian dans Ubuntu et qu’y changez-vous ?
R Lucas Nussbaum a donné quelques statistiques à ce sujet, il y a quelques années. Je vous invite à aller consulter sa présentation très complète sur http://www.lucas-nussbaum.net/blog/?p=444. Les chiffres n’ont pas dû évoluer beaucoup et je dois préciser que nous avons toujours environ 70% de paquets en provenance directe de Debian inchangés, 15% de logiciels modifiés pour nos outils et dépendances (la plupart du temps, des nouveautés) et le restant est constitué de paquets spécifiques Ubuntu en provenance de nos développeurs pour lesquels nous souhaitons rester en avance de phase.
Nous avons deux types de différences principales : - nous nous concentrons sur l’expérience utilisateur (je ne parle pas ici des variantes type Kubuntu, Lubuntu, etc.) et nous devons faire des choix draconiens en ce sens, quand bien même cela implique de modifier ou diversifier des composantes des sources amont. C’est un des charmes de l’univers du logiciel libre : si cela ne convient pas à vos attentes, vous pouvez le modifier légèrement. - nous expérimentons également en précurseurs des choses comme des indicateurs plus stricts pour le compilateur, le remplacement du bash par le dash ou l’ajout du support multi-architecture. Ce type de progrès en avance de phase (qui prennent beaucoup de temps pour s’assurer que l’ensemble des paquets dans l’archive va fonctionner avec) sont généralement repris par la suite dans Debian. Ubuntu assume donc les principales difficultés de ces transitions et Debian en bénéficie ensuite.
Q How many teams construct Ubuntu (and who are they), and how is the work divided between the in-house/community teams?
A This is, surprisingly, a difficult question to answer. We have different teams in Canonical contributing to Ubuntu: the desktop team, foundations team, server team, kernel team, security team, community team, QA team, archive admins, release team, but, in addition to that, we also have some upstreams like the team making the Unity or Ubuntu-one experience, who don’t have upload rights to Ubuntu, but, by their code, really contribute to the distro. Also, there are a lot of focused teams by flavors, like Kubuntu, Lubuntu, Xubuntu, Edubuntu, Ubuntu Studio… Some of them have people overlapping as well. Not counting even the translations and documentation teams…
Also, if you count “constructing Ubuntu”, we shouldn’t forget all other upstreams like Gnome, Xorg, OpenStack, as well as the Debian developers and the whole LOCO ecosystem. We all build Ubuntu in some way. Even people helping each other in a forum, or writing a document on a wiki, is building Ubuntu in their way. Also, maintaining the websites, even if they don’t touch directly to Ubuntu, and contributing to launchpad or the main web site, they are contributing to Ubuntu.
Q Combien d’équipes contribuent à la construction d’Ubuntu (et quelles sont-elles), et comment le travail est-il réparti entre les équipes maison et celles de la communauté ?
R Paradoxalement, c’est une question à laquelle il est difficile de répondre. Nous avons plusieurs équipes chez Canonical qui contribuent à Ubuntu : l’équipe du bureau, celle des fondations, celle de la partie serveur, celle du noyau, l’équipe sécurité, l’équipe en charge de la communauté, celle en charge de l’assurance qualité, l’administration des archives, l’équipe en charge de la sortie des versions ; mais, en plus de tout cela, nous avons également quelques canaux amont tels que les équipes construisant l’interface d’Unity ou d’Ubuntu-One qui n’ont pas de droit d’ajout direct à Ubuntu, mais qui, via leur code, apportent une contribution de premier ordre à la distribution. A côté de cela, il y a de nombreuses équipes dédiées aux variantes comme Kubuntu, Lubuntu, Xubuntu, Edubuntu, Ubuntu Studio… Certaines équipes comportent des personnes travaillant pour d’autres également. Sans compter les équipes en charge des traductions et de la documentation… En outre, si vous considérez la « construction d’Ubuntu », nous ne devons pas oublier tous les autres canaux tels que Gnome, Xorg, OpenStack, de même que les développeurs Debian et l’ensemble de l’écosystème LOCO. Nous construisons tous Ubuntu d’une manière ou d’une autre. Egalement, les personnes qui en aident d’autres à travers un forum, ou en écrivant un document sur un wiki, participent à leur manière à la construction d’Ubuntu. Enfin, la maintenance des sites internet, quand bien même cela ne touche pas directement à Ubuntu, la contribution au launchpad ou au site principal est une forme de contribution à Ubuntu.
DEVELOPMENT
Q What do the teams program in? C? Assembly? Amiga Basic (just kidding!)?
A No Amiga Basic AFAIK! Most of the development we are doing is mainly in C, C++, Python, Vala, Go, and shell of course. We need to have some fluency as well on autotools, cmake and makefile syntax. Sometimes, we have to touch perl when we really need to.
Développement
Q En quel langage les équipes programment-elles ? C ? Assembleur ? Amiga basic (je plaisante) ?
R Pas en Amiga basic, pour autant que je sache ! La plupart de nos développements se fait en C , C++, Python, Vala, Go, et en langage shell, bien entendu. Nous devons également maîtriser les autotools, cmake et make faile. Parfois, nous utilisons perl si nous en avons réellement besoin.
Q Do you have in-house specialists for networking, drivers, etc.?
A Indeed, even if we are “divided” across the teams, it doesn’t mean everyone is doing everything. We all have some specialization (but not restricted to it). So, we have Mathieu in charge of network manager, the kernel team is responsible for the kernel drivers.
Q Avez-vous des spécialistes maison du réseau, des pilotes, etc. ?
R Bien entendu. Quand bien même nous sommes répartis en plusieurs équipes, cela ne signifie pas que tout le monde fait de tout. Nous avons tous nos spécialités (mais nous ne nous y limitons pas). Nous avons donc Mathieu qui est en charge du gestionnaire réseau et l’équipe noyau est en charge des pilotes liés au noyau.
Q Do you use VMware/VirtualBox while developing Ubuntu?
A Not really, we do run it natively on our day-to-day laptop, which is way better, isn’t it? Right now, my daily machine is on Raring (the development release), for instance.
Q Utilisez-vous VMware/VirtualBox durant le développement d’Ubuntu ?
R Pas vraiment. Nous l’exécutons sur plateforme native sur notre portable éphémère, ce qui est mieux, n’est-ce pas ? Pour l’heure, par exemple, ma machine de tous les jours tourne sous Raring (la version en cours de développement).
Q How do all the programmers/teams communicate?
A We are using IRC (on freenode) for most of our discussions; others, needing less instant feedback but more development, are on the mailing lists (https://lists.ubuntu.com/). Everything is public, and you can even read the logs of the different channels ordered by date since Ubuntu’s creation – available at http://irclogs.ubuntu.com/.
Q Comment toutes ces équipes et programmeurs communiquent-ils entre eux ?
R Nous utilisons IRC (sur freenode) pour la plupart de nos échanges. D’autres, attendant moins de réactivité, mais d’avantage de développement, sont sous listes de messagerie (https://lists.ubuntu.com/). Tout est public et vous pouvez accéder en lecture à l’ensemble des ajouts ordonnés par date depuis la création d’Ubuntu (disponible à l’adresse http://irclogs.ubuntu.com/).
Q How do you keep up with all the changes in hardware which Ubuntu needs to run on?
A The kernel team is just awesome doing this task. Of course, most of the changes are directly coming at the Linux kernel level and we benefit from those new supports, taking always the latest available kernel, but the hardware enablement team is working on enabling more and more hardware as well.
Q Comment assurez-vous la prise en charge de toutes les évolutions matérielles sur lesquelles Ubuntu doit fonctionner ?
R C’est le formidable travail réalisé par l’équipe en charge du noyau. Bien entendu, la plupart de ces évolutions sont directement prises en compte au niveau du noyau Linux de base et nous en bénéficions en prenant toujours en compte la dernière version du noyau, mais l’équipe responsable de la compatibilité matérielle travaille également à ce que toujours davantage de matériel soit pris en charge.
Q How is all the code organised between teams/individuals?
A Historically, we just had 2 divisions: core developers (https://launchpad.net/~ubuntu-core-dev) who can change any part of the archive, and MOTU (master of the universe: https://launchpad.net/~motu) who can modify only what is in universe/multiverse. Main is a smaller asset than universe which is self contained (meaning, we can build main with main components only), and basically (to really simplify, it’s not a 1-to-1 match) contains what is supported officially and installed by default in Ubuntu (not flavors).
Nowadays, the landscape is more complicated. We have package sets, when people can earn their upload rights to only, for instance, the “desktop components”; we also have per package upload rights for people interested in just one particular component. You can find all those detailed on https://wiki.ubuntu.com/UbuntuDevelopers.
Q Comment le code est-il organisé entre les équipes et les individus ?
R Historiquement, nous n’avions que 2 divisions : les « core développeurs » (https://launchpad.net/~ubuntu-core-dev) qui peuvent modifier n’importe quel élément d’une archive, et les MOTU (maîtres de l’univers : https://launchpad.net/~motu) qui ne peuvent agir que sur ce qui relève du logiciel communautaire (universe) ou soumis à droit d’auteur ou restriction légale (multiverse). La partie maintenue par Canonical (Main) est moins versatile que la partie communautaire, qui est autonome, car Main ne peut être construit qu’avec des composants Main, et typiquement (histoire de simplifier car ce n’est pas strictement ça) contient ce qui est officiellement supporté et installé par défaut dans Ubuntu (pas dans les versions dérivées). Aujourd’hui, le panorama est plus complexe. Nous avons des ensembles de paquets sur lesquels certaines personnes ont un droit restreint de mise à jour : par exemple, les composants du bureau. Nous avons également des droits de mise à jour limités par paquet pour les personnes qui ne s’intéressent qu’à un composant en particulier. Vous pouvez trouver le détail de tout cela à l’adresse https://wiki.ubuntu.com/UbuntuDevelopers.
Q How is the code compiled? What hardware is used in compiling, and how long does it take?
A We are building Raring on 4 differents types of architectures: i386 (classic 32-bit machines, the default), amd64 (64-bit), powerpc (previous Apple machines processor architecture), and armhf.
This means that each package and sources are built on those 4 different kind of architectures, and, depending on what you install Ubuntu on, it will install packages built for your machine (this is a simplification again, we do have some packages like images assets, that are built only once, because they don’t contain code that will produce different results from one architecture to another one).
What is happening is that Ubuntu developers are uploading (by ftp) a signed source package to launchpad. Then the build farm (https://launchpad.net/builders) will pick them up and split the load between the different machines. Once it’s done, the binary package is published in the main archive, and then will get replicated to the Ubuntu mirrors.
Another source is the Debian repository, as we are syncing at the start of each release from Debian all packages we can sync (meaning there have been no Ubuntu changes compared to Debian – the 70% I was talking about earlier).
Of course, there are additional manual reviews for new packages, or packages needing to migrate from universe to main and so on…
Q Comment le code est-il compilé ? Quelles machines sont utilisées pour la compilation et combien de temps cela prend-il ?
R Nous construisons Raring sur 4 architectures différentes : i386 (les machines 32 bits standard, par défaut), amd64 (64 bits), powerpc (l’architecture des anciens processeurs Apple), et armhf. Cela implique que chaque paquet et source soit construit sur chacune de ces 4 architectures et, en fonction de ce sur quoi vous installerez Ubuntu, ne seront installés que les paquets adaptés à votre machine (encore une fois, c’est une vision simplifiée car nous avons des paquets tels que les ensembles de fichiers images qui ne sont construits qu’une fois puisqu’ils ne contiennent aucun code susceptible de produire un comportement différent d’une architecture à l’autre). Dans la pratique, les développeurs Ubuntu vont télécharger (via ftp) un paquet source signé vers le launchpad. Le site de compilation (https://launchpad.net/builders) va venir les prendre et répartir la charge entre les différentes machines. Cela fait, le paquet binaire est publié dans l’archive principale et sera ensuite répliqué sur les différents sites miroirs Ubuntu. Une autre source provient des dépôts Debian, puisque nous nous synchronisons au début de chaque version avec tous les paquets Debian possibles (à savoir ceux pour lesquels il n’y a pas eu de modification Ubuntu - les 70% que j’évoquais tout à l’heure). Bien entendu, il y a des vérifications manuelles complémentaires pour les nouveaux paquets ou les paquets nécessitant une migration de universe vers main, ou autre.
Q Is the kernel tweaked specifically for Ubuntu?
A Indeed, the kernel is changed for Ubuntu. Most of the changes are reversed back to the Linux kernel itself, but always taking the latest kernel helps doing some QA, spotting regressions and getting them fixed.
Q Le noyau fait-il l’objet d’une adaptation spécifique pour Ubuntu ?
R Effectivement, le noyau est modifié pour Ubuntu. La plupart des changements sont ensuite réinjectés dans le noyau Linux lui-même, mais le fait d’utiliser la dernière version du noyau permet de travailler l’assurance qualité en pointant du doigt les régressions et en les corrigeant.
Q Is it possible for users to acquire parts of the Ubuntu code for modification? If so, where do they download it?
A That’s really easy, and part of the default toolset. You have to enable the “source” repository (in /etc/apt/sources.list), or using Software Sources and enabling the “source code” checkbox. After a refresh from the repository, you can download any source you want from the command line using apt-get source <package_name>. Want the Unity source?
apt-get source unity.
Q Est-il possible pour un utilisateur d’accéder à des parties du code Ubuntu pour les modifier ? Si oui, où peut-il se les procurer ?
R C’est très simple et cela fait partie de la boîte à outils de base. Il vous faut autoriser les dépôts « source » (dans /etc.apt/sources.list) ou cocher la case « code source » dans le gestionnaire de dépôts. Après mise à jour des dépôts, vous pouvez télécharger n’importe quelle source via la ligne de commande : apt-get source <nom_du_paquet>. Vous voulez la source de Unity ? apt-get source unity
AE
REPOSITORIES Q Are the repositories maintained by the community, or does Canonical look after them? A The repository needs to have a level of security and high reliability. As the repositories are signing the binary packages with their private keys, we need to be accountable for what we deliver to our users and ensure there is no possibility to introduce evil content with the right signing. There are only very few people accessing those machines, with some Canonical IT guys and some old/long time Ubuntu developers (employed by Canonical). Also, you will notice that Canonical is funding the high cost of bandwidth and maintenance of those critical pieces. Q Is there a person/team who looks after the Ubuntu Software Center side of things, or is it just a front end for Synaptic? A There is a small team led by Michael Vogt delivering Ubuntu Software Center; you should also know that he’s a long time apt contributor, maintainer of Synaptic, the previous gnome-app-install, and upgrade-manager. So you can see that those pieces are all tied together by the same people (and it’s quite funny to read on forums that people creating Synaptic are genius, and not the Ubuntu Software Center or the contrary).
LES DÉPÔTS
Q Les dépôts sont-ils maintenus par la communauté ou est-ce Canonical qui s'en occupe ?
R Le dépôt a besoin d'un niveau de sécurité et d'avoir une grande fiabilité. Puisque les dépôts signent les paquets binaires avec leurs clés privées, nous devons être responsables vis-à-vis des utilisateurs et nous assurer qu'il n'y a aucune possibilité d'y introduire du contenu mauvais avec la bonne signature. Très peu de gens peuvent accéder à ces machines : quelques personnes du département TI de Canonical et quelques vieux développeurs Ubuntu qui y travaillent depuis longtemps et qui sont employés par Canonical. Qui plus est, vous remarquerez que c'est Canonical qui finance le coût de la bande passante et de l'entretien de ces parties critiques.
Q Y a-t-il une personne/équipe qui s'occupe de la Logithèque Ubuntu ou n'est-elle qu'une interface pour Synaptic ?
R Il y a une petite équipe gérée par Michael Vogt qui livre la Logithèque Ubuntu ; vous devez savoir aussi que Vogt est, depuis longtemps, un contributeur apt, un responsable de Synaptic, du précédent gnome-app-install et gestionnaire de mises à jour. Ainsi, vous pourrez constater que toutes ces parties sont rassemblées par les mêmes personnes (et c'est très amusant de lire sur les forums que les gens qui s'occupent de Synaptic sont des génies, mais pas ceux qui s'occupent de la Logithèque, ou le contraire).
Q How much hardware does it take to run the repositories? A Wow, I have really no idea for that TBH – “a lot of bandwidth”. Don’t forget that the repositories’ content is mirrored to a lot of places to get lower latency. Those servers are not maintained by Canonical, but as told previously, the main archive contents are signed. We distribute the corresponding signatures to the user machines, and thus apt is able to check the integrity of the archive copy on the mirrors, and so we can ensure nothing was changed in between. TESTING Q How many people/teams test Ubuntu, and how often? Also, how is testing done? Is it per package, or as a whole distro? A There is the community team’s awesome Nicholas Skaggs leading an effort to have more and more community participation on testing. In addition to that, we have the QA team, making regular install and upgrade testing. Testing upgrades from release to release is a really difficult task, especially with the transitions and other things changing between releases. To address that, we have automated upgrade testing which installs an older version of Ubuntu on a machine, changes some configurations, and upgrades to the next release. We also have a daily automated latest ISO installer, ensuring that the latest produced ISO can be installed every day. So, we do have multiple kinds of testing: • unit testing that’s enabled during package build. The build will fail if it doesn’t pass. • auto package testing, which is testing against the installed version of the component. Those won’t be copied into the release pocket if they don’t pass. • ISO and upgrade testing, made every day and automatically. • ISO and some components manual testing, on a regular basis (Nicholas is trying to get help on this, follow planet Ubuntu to get more info). • some components like the whole Unity ecosystem (60 components) have additional tests that are run on a daily basis even before it’s uploaded to distro.
Q Quelle quantité de matériel est nécessaire pour faire fonctionner les dépôts ?
R Ouah, pour être honnête je n'en ai aucune idée - « des tonnes de bande passante ». N'oubliez pas que le contenu des dépôts est dupliqué à beaucoup d'endroits pour diminuer la période de latence. Ces serveurs-là ne sont pas entretenus par Canonical, mais, comme j'ai dit précédemment, le contenu principal des archives est signé. Nous distribuons les signatures correspondantes aux machines utilisatrices et, de cette façon, apt peut vérifier l'intégrité de la copie de l'archive sur ces sites et nous pouvons nous assurer que rien n'a été modifié entre les deux.
LES TESTS
Q Combien de gens/équipes testent Ubuntu et à quelle fréquence ? Et puis comment sont faits les tests ? Par paquet individuel ou en tant que distrib. entière ?
R Le génial Nicholas Skaggs de l'équipe communautaire dirige une action pour une nette augmentation de la participation communautaire dans les tests. De plus, nous avons l'équipe d'Assurance qualité qui fait des tests d'installation et de mise à niveau très régulièrement.
Faire des test de mises à niveaux de sortie en sortie est vraiment très difficile, surtout avec les transitions et d'autres modifications faites entre les sorties. Pour répondre à ce problème, nous avons des tests de mise à niveaux automatisés ; ceux-ci installent une ancienne version d'Ubuntu sur une machine, en modifient quelques configurations et font une mise à niveau vers la version suivante. Nous avons aussi un installeur automatisé quotidien de l'ISO la plus récente, pour assurer que la toute dernière ISO peut être installée chaque jour.
Ainsi, nous avons en fait de multiples sortes de tests : * les tests à l'unité qui sont activés pendant la création d'un paquet. Cette création échouera s'il ne réussit pas le test ; * les tests auto des paquets, qui sont des tests comparant le paquet avec la version installée du composant. Les nouveaux paquets ne seront pas copiés dans la version qui sortira s'ils ne passent pas le test avec succès ; * les tests de mises à niveau et des ISO, qui sont automatisés et faits quotidiennement ; * des tests manuels réguliers d'ISO et de certains composants (Nicholas essaie d'obtenir de l'aide pour ces tests ; suivez Planet Ubuntu pour davantage de renseignements) ; * certains composants tels que l'écosystème entier d'Unity (60 composants) subissent des tests supplémentaires quotidiens même avant leur téléchargement vers une distrib.
Q How do you ensure that vital/necessary packages aren’t missing? A We are getting more and more automated tests enabling running a full session and testing applications as well as core experience. This is how we can see that a critical piece, after a daily ISO installation, is missing. Note as well that packaging missing by accident will probably be on a mismatch component list (missing from main or being there for no reason) – this is another way of spotting this :) If the latest ISO couldn’t build due to a missing components or a mismatch, we’ll notice it quickly. Mismatch shouldn’t happen anymore with additional steps we introduced in Raring. Now all packages are going to a proposed pocket (similar to when we do Stable Release Updates), and are validated there before being copied to the release pocket which is the main archive. This validation ensures we don’t get the archive into a non-working state. Q Do you test on old machines? Eg: parallel port, floppy disk, etc. A This is with manual testing most of the time. Martin Pitt is introducing some mock objects (fake objects used for testing target) to be able to spot regression for old configurations like that, but, let’s be honest, Ubuntu’s goal is not to be able to run on so old hardware, there are other distributions targeted for 10+ year-old machine :)
Q Comment vous assurez-vous que des paquets vitaux/nécessaires ne manquent pas ?
R Nous activons de plus en plus de tests automatisés ; ceux-ci exécutent une session entière et testent les noyaux aussi bien que les applications. C'est comme cela que nous pouvons voir si une partie critique manque, après l'installation quotidienne de l'ISO.
Remarquez aussi que des paquets qui manquent accidentellement se trouveront sans doute sur une liste de disparités des composants (qui manquent au « main » ou qui y sont sans raison - c'est une deuxième façon de les repérer) : Si l'ISO la plus récente n'a pas pu se créer à cause de composants manquants ou de disparités, nous le remarquerons très rapidement.
Les disparités ne devraient plus arriver avec les étapes supplémentaires que nous avons introduites dans Raring Ringtail (la prochaine version). Actuellement, tous les paquets sont dirigés vers un « proposed pocket » (semblable à ce que nous faisons avec les mises à jour vers des versions stables) et y sont validés avant d'être copiés vers le « pocket » de la sortie, qui est en fait l'archive principale. Cette validation garantit que nous ne cassons pas l'archive.
Q Est-ce que vous faites des tests sur de vieilles machines ? Avec, notamment, port parallèle, disquette, etc. ?
R Il s'agit de tests manuel la plupart du temps. Martin Pitt introduit des objets factices (utilisés pour tester la cible) pour être capable de noter une régression pour de telles vieilles configurations, mais, soyons honnêtes, l'objectif d'Ubuntu n'est pas d'être capable de fonctionner sur un matériel très ancien, car il y a d'autres distributions qui ciblent des machines de 10 ans et plus :)
Q Is Ubuntu benchmarked during production, or prior to release? A We have some limited automated benchmarks, but this is an area we are developing and are getting better and better with each release. This and automated testing are two historical weak focal points of free software. Nowadays, Ubuntu is changing this mindset, putting them at the core of the user experience. We are then growing on this and helping the whole ecosystem to evolve on it. Q Is there an easy way (for users/testers) to follow a bug from reporting to fixing? A Quite easy! Just find it on launchpad (normally, it’s way more efficient to search directly on the component you think that is impacted by the bug), and click on the subscribe button on https://bugs.launchpad.net/ubuntu/+bug/1. You will get all notification (and numerous comments) on status changes. When the Ubuntu component of the bug is marked as “Fix Released”, this means that the fix is now in the development version. You can, on the launchpad interface, ask for backporting the fix to an older release and track its status here. Q Is there a process for determining the origin of a defect in a test? A This is based more on experience of the distro, knowing which components do what and dogfooding [http://en.wikipedia.org/wiki/Eating_your_own_dog_food]. Triaging bugs are a good start to get an overall overview on the components of a Ubuntu distribution and understanding what can be the root cause of a problem.
Q Est-ce que vous faites du « benchmarking » pendant la production ou avant une sortie ?
R Nous avons quelques « benchmarks » limités automatisés, mais c'est un domaine que nous développons et nous nous améliorons de plus en plus avec chaque sortie. Historiquement, ceux-ci et les tests automatisés sont des faiblesses des logiciels FOSS. Aujourd'hui, Ubuntu modifie cette mentalité et met les deux au cœur de l'expérience utilisateur. Ensuite, ils veulent croître à ce sujet pour aider l'écosystème entier à évoluer.
Q Comment les utilisateurs/testeurs peuvent-ils facilement suivre un bogue, du rapport jusqu'à sa réparation ?
R C'est très facile ! Il suffit de le trouver sur Launchpad (en général, c'est bien plus efficace de faire des recherches sur le composant que vous croyez impacté par le bogue) et de cliquer sur le bouton « subscribe » (abonnez-vous) sur https://bugs.launchpad.net/ubuntu/+bug/1. Vous recevrez toutes les notifications (et de nombreux commentaires) de modifications de son statut. Quand le composant Ubuntu concerné par le bogue est balisé « Fix Released », cela veut dire que la réparation se trouve dans la version développement. Sur l'interface de Launchpad, vous pouvez demander que la réparation soit portée vers une version antérieure et suivre son statut ici.
Q Existe-t-il un processus pour déterminer l'origine d'un défaut révélé pendant un test ?
R Cela est basé davantage sur l'expérience de la distrib., sachant quels composants font quoi et le « dogfooding » http://en.wikipedia.org/wiki/Eating_your_own_dog_food ; [Ndt : utiliser un produit pour démontrer sa qualité, dans une sorte de témoignage publicitaire.] Le triage des bogues est une bonne façon d'avoir une vue d'ensemble des composants d'une distribution Ubuntu et de commencer à comprendre les principales causes à l'origine d'un problème.
RELEASE Q How is the final ISO compiled? A The ISO is compiled every day, and you can find it at http://cdimage.ubuntu.com/daily-live/current/ for Ubuntu itself. (changing the url, you can find the different flavors). A program called “germinate” (https://wiki.ubuntu.com/Germinate) takes some description/configuration files for what we install by default (called the “seeds”, https://wiki.ubuntu.com/SeedManagement), and ensures that it’s installing all the necessary dependencies. From this list, this will be installed in a live session with some additional packages to compress the image and produce a daily ISO. So the final ISO is not that different from a daily one, it’s just that we don’t push any more packages unless their selected fixes are near the end of the development cycle (processes are changing as well, so we also don’t push any more new features), and, at some point, this ISO becomes the official one once the test results are in a good shape and we are proud of the quality to deliver it to our users. We are trying to be more and more confident on features before pushing them to Ubuntu so that this stabilization period will become shorter and shorter, and even, why not, at some point, being able to say “each daily ISO can be the final one”.
LES SORTIES
Q Comment se fait la compilation de l'ISO finale ?
R L'ISO est compilée tous les jours et vous la trouverez, pour Ubuntu lui-même, à http://cdimage.ubuntu.com/daily-live/current (en changeant l'URL, vous trouverez les variétés différentes). Un programme appelé « germinate » (https://wiki.ubuntu.com/Germinate) prend quelques fichiers de description/configuration pour ce que nous installons par défaut (appelés les « seeds » (graines), https://wiki.ubuntu.com/SeedManagement), et s'assure qu'il installe toutes les dépendances nécessaires. À partir de cette liste, ce sera installé au cours d'une session live avec quelques paquets supplémentaires pour compresser l'image et produire une ISO quotidienne.
Ainsi, l'ISO finale n'est pas si différente que cela d'une ISO quotidienne, si ce n'est que nous ne poussons plus de paquets à moins que leurs réparations sélectionnées ne soient proches de la fin du cycle de développement (les processus changent aussi et nous ne poussons donc aucune autre nouvelle fonctionnalité) et, à un moment donné, cette ISO devient officielle, une fois que les résultats des tests sont bons et que nous soyons assez fiers de leur qualité pour vouloir la livrer à nos utilisateurs.
Nous essayons d'avoir de plus en plus de confiance dans des fonctionnalités avant de les pousser vers Ubuntu, afin que la période de stabilisation devienne de plus en plus courte, et même - pourquoi pas ? - à un moment donné, pouvoir dire que « chaque ISO peut être l'ISO finale ».
Q Who gives the final nod to release the ISO? A The release team decides to call the ISO “final”. They traditionally gather in the London Bluefinn office for the release week to produce, and ensure everything is in one piece (and apparently drinking champagne once the release is announced), while the other remote employees and community are drinking water at home. Q How is the ISO distributed to the various mirrors? A I’m not familiar with the exact technical side, it’s copied to a place that other mirrors are watching, and then rsynced as far as I know. Q How are the various Ubuntu derivatives released? Do they get early access to the final ISO, or are they (X/L/Kubuntu) all separately compiled from Ubuntu? A The flavors (not derivatives) are built from exactly the same archives as Ubuntu. So, when you install Shotwell on Ubuntu or Kubuntu, it’s exactly the same binary package that is installed. The only differences are the set of packages that are installed and selected by default. For those, a separate ISO is produced by germinate taking a different seed; it uses a different configuration file for what is installed by default.
Q Qui est-ce qui décide in fine de sortir l'ISO ?
R C'est l'équipe de la version qui décide d'appeler l'ISO « finale ». Ces membres ont l'habitude de se rassembler dans le bureau Bluefinn de Londres, la semaine de la sortie, pour la produire et s'assurer que tout est comme il faut (j'ai entendu dire qu'ils sabrent le champagne une fois la sortie annoncée, alors que les employés à distance - et la communauté - boivent de l'eau chez eux.
Q Comment l'ISO est-elle distribuée au divers sites de téléchargement ?
R Je ne connais pas trop ce côté technique précis. Elle est copiée vers un emplacement que les autres sites miroirs surveillent et ensuite, pour autant que je sache, on utilise rsync.
Q Les divers dérivés d'Ubuntu sortent comment ? Est-ce qu'ils ont rapidement accès à l'ISO finale ou sont-ils (X/L/Kubuntu) compilés séparément ?
R Les variétés (et non pas les dérivés) sont créées à partir des mêmes archives qu'Ubuntu. Ainsi, quand vous installez Shotwell sur Ubuntu ou Kubuntu, c'est exactement le même paquet binaire qui est installé. Les seules différences sont l'ensemble des paquets installés et sélectionnés par défaut. Pour ceux-là, une ISO distincte est produite par germinate qui se sert d'une graine différente ; il utilise un fichier de configuration différente pour ce qui est installé par défaut.
Other Info: Let me just point to some links: https://wiki.ubuntu.com/UbuntuDevelopment for developing Ubuntu, a good start guide. http://developer.ubuntu.com/ for developing apps ON Ubuntu https://wiki.ubuntu.com/RaringRingtail/ReleaseSchedule for the Ubuntu release schedule (for Raring) http://status.ubuntu.com/ubuntu-raring/ to follow features and status on them that people working on Ubuntu are implementing For testing and results, Nicholas is publishing a call for testing on planet.ubuntu.com, so watch this space.
Informations supplémentaires :
Permettez-moi de vous donner tout simplement quelque liens :
https://wiki.ubuntu.com/UbuntuDevelopment pour le développement d'Ubuntu, un bon guide pour commencer.
http://developer.ubuntu.com/ pour développer des applis SOUS Ubuntu.
https://wiki.ubuntu.com/RaringRingtail/ReleaseSchedule pour le planning de la sortie Ubuntu (de Raring Ringtail).
http://status.ubuntu.com/ubuntu-raring/ pour suivre des fonctionnalités implémentées par des gens qui travaillent sur Ubuntu, et leur statut.
Pour ce qui concerne les tests et leurs résultats, Nicolas publie un appel pour des testeurs sur planet.ubuntu.com, alors surveiller ce site.