Différences

Ci-dessous, les différences entre deux révisions de la page.

--- issue68:special_q_a [2013/03/24 15:26] – nico
+++ issue68:special_q_a [2013/03/24 18:28] (Version actuelle) – andre_domenech
@@ Ligne 30: / Ligne 30: @@
 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.
+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.
@@ Ligne 38: / Ligne 38: @@
 **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 ?
+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.
@@ Ligne 55: / Ligne 55: @@
 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  des nos développeurs pour lesquels nous souhaitons rester en avance de phase.
+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, …) 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 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.
+- 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?**
@@ Ligne 67: / Ligne 67: @@
 **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 comme le travail est-il réparti entre les équipes maison et celles de la communauté ?
+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^mee que les développeurs Debian et l’ensemble de l’écosystème LOCO. Nous construisont tous Ubunt u 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.
+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.
@@ Ligne 78: / Ligne 78: @@
 **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?**
@@ Ligne 100: / Ligne 128: @@
 **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?**
@@ Ligne 112: / Ligne 147: @@
 **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?**
@@ Ligne 122: / Ligne 173: @@
 **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 =====
@@ Ligne 137: / Ligne 193: @@
 LES DÉPÔTS
-Q Les dépôts sont-ils maintenus par la communauté ou est-ce que c'est Canonical qui s'en occupe ?
+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 mployé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.
+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 ?
-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).
+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?
@@ Ligne 166: / Ligne 222: @@
 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. C'est serveurs-là ne sont pas entretenus par Canonical, mais, comme j'ai dit précédemment, le continu 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 ne fut modifié entre les deux.
+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
@@ Ligne 174: / Ligne 230: @@
 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é chaque jour.
+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 à 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 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 à niveaux et des ISO, qui sont automatisés et faits quotidiennement.
+* 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).
+* 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.
@@ Ligne 195: / Ligne 251: @@
 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 assurer vous que des paquets vitaux/nécessaires ne manquent pas ?
+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 raisons) - 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.
+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 vielles machines ? Avec, notamment, port parallèle, disquette, etc.
+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 :)
@@ Ligne 225: / Ligne 281: @@
 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.
+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.
+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
@@ Ligne 245: / Ligne 301: @@
 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 toues 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.
+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, 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 soient bonnes et que nous en soyons assez fiers de la qualité pour vouloir la livrer à nos utilisateurs.
+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 court, et même - pourquoi pas ? - à un moment donné, pouvoir dire que « chaque ISO peut être l'ISO finale ».
+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?
@@ Ligne 265: / Ligne 321: @@
 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 pour 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ées à distance et la communauté boivent de l'eau chez eux.
+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, tant que je sache, on utilise rsync.
+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 ?
+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.
@@ Ligne 296: / Ligne 352: @@
 Informations supplémentaires :
-Permettez-moi de vous donnez tout simplement quelque liens :
+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
+pour le développement d'Ubuntu, un bon guide pour commencer.
 http://developer.ubuntu.com/
-pour développer des applis SOUS Ubuntu
+pour développer des applis SOUS Ubuntu.
 https://wiki.ubuntu.com/RaringRingtail/ReleaseSchedule
-pour le planning de la sortie Ubuntu (de Raring Ringtail)
+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 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.