Geckozone est un Club Unesco

Plan de développement de Mozilla

Profil(s) : Tous
Date : 1er juin 2004
Auteur : Bouiaw

Version originale par Brendan Eich, David Hyatt
Traduit de l’anglais par Sébastien Deleuze

Bienvenue sur le plan de développement de Mozilla. Ce document est la troisième modification majeure depuis le plan de développement original publié en 1998 qui définissait les nouveaux objectifs de mozilla en terme de conformité aux standards, de modularité et de portabilité. Le plan de développement précédent concernait les versions « milestones », les règles de développement jusqu’à Mozilla 1.3 et contenait des liens vers les plans de développement précédents.

Nous avons parcouru beaucoup de chemin depuis. Nous avons terminé Mozilla 1.0 qui satisfait les critères énoncés dans le manifeste. Cela a donné à la communauté et au reste du monde un très bon logiciel, ainsi qu’une branche stable pour les développements de maintenance et des produits dérivés.

Allez voir le Mozilla Hall of Fame pour avoir une liste de tous les projets et produits qui ont tiré profits de la version 1.0.

Depuis la 1.0 jusqu’à la 1.3, nous avons continué le travail entamé durant les version 0.9.x sur l’empreinte mémoire et les performances, tout en résolvant un grand nombre de problèmes présents depuis très longtemps dans le code source initié en 1998.

On a pu voir l’émergence de fonctionnalités importantes telles que la navigation par onglets, le blocage des popups ou encore le filtrage bayésien du spam inspiré de http://paulgraham.com. Les projets spécifiques aux navigateurs, tels que Mozilla Firefox (anciennement Firebird, lui même anciennement Phoenix) et Camino (anciennement Chimera) ont également beaucoup avancé.

Un nouveau plan de développement

Mais un développement tel que nous l’avons mené depuis la version 1.0 est insuffisant pour un projet open source dynamique tel que le nôtre. Il apparaît clairement que Mozilla a besoin d’un nouveau plan de développement.

Nous allons proposer ci-dessous une nouvelle architecture basée sur le Gecko Runtime Environment (GRE), qui pourra être partagée entre plusieurs applications. Avant de parler du principe et des différences avec l’ancienne architecture, voici les conséquences de ce changement :

- Changement du navigateur intégré basé sur XPFE pour le navigateur indépendant Mozilla Firefox. Note : l’interface utilisateur du nouveau navigateur est définie entièrement avec XUL. En le choisissant, nous montrons combien XUL est une base solide pour des applications rapides et multi-plateformes telles que Mozilla Firefox.

- Le développement d’un logiciel de messagerie séparé destiné à être utilisé avec Mozilla Firefox a déjà commencé sous le nom de code Thunderbird, mais il est basé sur le nouveau toolkit XUL utilisé par Firefox Note : ce nouveau toolkit est une réimplémentation compatible du toolkit XPFE, avec des fonctionnalités supplémentaires comme les barres d’outils personnalisables. Nous ne commençons pas un nouveau toolkit, nous changeons simplement pour le toolkit XUL de dernière génération.

- Fournir une version 1.4 de Mozilla qui puisse remplacer la 1.0 en tant que branche stable de développement, puis réaliser les changements les plus risqués pendant le développement des versions 1.5 et 1.6. Les changements les plus importants après la 1.4 seront dus au passage vers Mozilla Firefox et Thunderbird, et au gros travail qui sera réalisé sur ces deux éléments.

- Résoudre les bugs critiques présents dans le moteur de rendu de Gecko, pour permettre une version plus maintenable, performante et extensible dans le futur.

- Continuer la mutation du modèle actuel (grand nombre de programmeurs avec un accès CVS illimité) vers un modèle plus courant dans le monde de l’open source, c’est à dire vers de petits modules avec des leaders fortement impliqués et une organisation claire et structurée comme avec NSPR, JavaScript et Gecko.

L’idée sous-jacente à ce plan de développement est de préférer la qualité à la quantité. Nous devons faire moins, mais le faire mieux, avec un solide mécanisme d’extensions, afin que (par exemple) la communauté ne bataille plus avec certains éléments de l’interface utilisateur tels que les menus.

Un autre exemple d’extensibilité : Gecko doit pouvoir supporter XML et ses dérivés (certains expérimentalement et sous certaines conditions) sans que chacun ait à manipuler le fichier nsCSSFrameConstructor.cpp. Cet énorme fichier devra être supprimer ou grandement simplifié par des modifications qui auront lieu durant le développement des versions 1.5, 1.6, et probablement après.

Il devrait être possible, en utilisant de bonnes bases (HTML, widgets XUL, SVG), des outils de composition et de mise en page (CSS, XBL), d’éviter une explosion de code C++ supplémentaire.

Discussion

Quand Netscape a libéré le code source de son navigateur le 31 Mars 1998, les prévisions, les plans et bien sûr la structure du code étaient orientés vers une continuation de la grosse suite d’applications (navigateur, messagerie, éditeur) promu par Netscape durant 4 ans. Cette approche du style « couteau suisse » continua lorsque nous avons reconstruit Mozilla autour de Gecko, XPFE et des interfaces XPCOM scriptables vers la fin de l’année 1998. Durant tout ce temps Mozilla a reçu une aide importante de la part de Netscape, principalement sous la forme de contributeurs rémunérés et de matériel.

Le résultat de tout cela est une suite riche et complexe d’applications et un grand nombre de modules pour l’interface utilisateur. Beaucoup de bonnes choses sont nées de cette ambitieuse intégration, comme par exemple XUL et XBL.

Si le but avait simplement été de « réécrire le navigateur », XUL aurait été une fausse économie. Cela est d’autant plus vrai que comme prévu, XPFE nous a permis d’écrire une interface utilisateur multi-plateforme une fois pour toute, au lieu de développer une interface basée sur les composants natifs des systèmes d’exploitation pour au moins trois plateformes. Mais nous avons fini par avoir au moins autant de personnes qui s’occupaient des différentes applications de la suite et de leur intégration que si nous avions utilisé des composants natifs pour l’interface et une base commune pour le navigateur.

Cette critique suppose que Mozilla, et ses contributeurs les plus importants tel que Netscape, se soit contentés de développer seulement un navigateur, sans logiciel de messagerie, sans lecteur de news et sans une architecture complète. En plus des importantes applications multi-plateformes qu’il a rendu possibles (la messagerie, l’éditeur HTML), XUL a été une grande avancée pour les développeurs d’extensions, les traducteurs, les distributeurs et les développeurs d’applications portables. Sans en avoir fait notre objectif principal, nous avons développé une architecture web multi-plateforme de grande qualité : la plateforme Mozilla.

Néanmoins, en ignorant des problèmes importants d’interface utilisateur, et en considérant seulement les objectifs minimums pour chaque application de la suite Mozilla, le coût de l’intégration a été très élevé. Les applications non intégrées ont tendance à être plus rapide à se charger, à consommer moins de mémoire et à être plus stables et plus robustes.

Autre exemple du coût élevé de l’intégration dans la suite Mozilla : la complexité et la surcharge de l’interface graphique (juste un exemple parmi tant d’autres : le sous-menu Fichier / Nouveau).

Le type d’utilisateurs visé par cette suite n’a jamais été clair et a varié en fonction de la tendance du moment et des contributeurs. Le blog de Hyatt est un vrai résumé de toutes les critiques qui peuvent être faites envers cette approche. Les meilleurs applications ne peuvent pas être gérées de façon globale : un tel sera plus motivé dans un domaine précis, alors qu’un autre sera moins motivé pour concevoir l’interface graphique par exemple.

Gecko a également souffert de la surenchère. Non pas à cause du grand nombre d’applications basées sur lui (cela a permis de corriger beaucoup de bugs de rendu et d’implémentation), mais parce qu’il est modulaire sans être facilement évolutif. Des parties de Gecko sont toujours baroques principalement à cause de problèmes dans l’architecture initiale et de l’accumulation de patchs.

Résumé des fondements

En résumé, et dans le même ordre que les éléments du plan de développement énoncés précédemment, voici les raisons d’être de ce nouveau plan :

- Mozilla Firefox est tout simplement plus petit, plus rapide et meilleur, non pas parce qu’il a chaque fonctionnalité voulu par chaque partie de la communauté Mozilla, mais parce qu’il possède un puissant mécanisme d’extensions. Nous admettons que des utilisateurs différents aient besoin de nombreuses fonctionnalités différentes ; une telle demande est donc légitime. Le fait d’essayer de « câbler » toutes ces fonctionnalités dans une suite d’applications intégrée n’est pas nécessaire. Ce n’est ni techniquement, ni fonctionnellement justifiable.

- Ce qui est vrai pour le navigateur l’est aussi pour le logiciel de messagerie. Celui qui est intégré à Mozilla a beaucoup de fonctions intéressantes, mais il est pénalisé par une trop grande intégration avec les autres applications. Il en résulte une interface complexe, maintenue par trop peu de personnes qui ont pour la plupart un autre travail.

- La branche de la version 1.0 est vieille d’un an. Il est temps de passer de la 1.0 à la 1.4 pour la branche de développement stable, afin de pouvoir bénéficier de toutes les améliorations au niveau de la stabilité, des performances et de la sécurité faites depuis la sortie de la version 1.0. Beaucoup de distributeurs ont l’intention de réaliser cette migration. Celle-ci a entraîné le gèle du tronc afin de faire des changements majeurs durant le développement des versions 1.5 et 1.6, mais en gardant les versions compilées quotidiennement, et les cycles alpha/bêta/version finale.

- Les développeurs de Gecko essayent de résoudre les problèmes d’architecture et de rendu qui ne peuvent être résolus avec des patchs. Ces problèmes empêchent actuellement des améliorations majeures au niveau de la maintenabilité, de la taille en mémoire, des performances et de l’extensibilité de Mozilla. Gecko serait plus facile à maintenir, plus rapide et quasiment aussi compact en mémoire simplement en réduisant la complexité de son code.

- Le faux modèle égalitaire d’accès CVS et d’organisation des sources qui date des premiers jours de Mozilla touche à sa fin. Beaucoup de programmeurs sont partis, laissant derrière eux des modules abandonnés ou affectés à d’autres personnes. Les différentes combinaisons de droits d’accès CVS a obligé mozilla.org à instituer une vérification systématique du code ce qui nécessite, si il est possible d’en trouver, un responsable du module en question.

A propos des responsables...

Ce dernier point est sujet à controverse. Attardons nous dessus durant quelques instants, et essayons de clarifier la situation.

- Les Super-reviews sont généralement une bonne chose et deux niveaux de vérification, l’un par un expert du domaine, l’autre par un généraliste expérimenté évitent la plupart du temps les modifications hasardeuses.

- Nous ne dévalorisons pas le travail de nettoyage des sources et de programmation du système de compilation qui est souvent réalisé par un petit nombre de volontaires dévoués, ce genre de travail doit continuer.

- Nous ne pensons pas non plus que les responsables aient toujours raison, ou qu’ils ne peuvent être remplacés.

Après avoir mis à mal toutes ces personnes, le point important à retenir est le suivant : il vaut mieux avoir un responsable compétent qui sait imposer ses décisions plutôt que de ne pas en avoir et de rester dans le flou (N.B. : un groupe de plus d’une personne n’est pas considéré comme un responsable.) Ce point est surtout vrai pour le design, la gestion des préférences, et encore plus pour l’interface utilisateur. Pour garder une interface utilisateur cohérente, il n’y a pas d’autre solution que d’avoir un « leader autoritaire ». Pour la cohérence nécessaire à une suite d’applications, nous attendons de ce leader qu’il sache communiquer, coopérer, et consolider les acquis.

Il est temps pour Mozilla de « revenir sur terre » : un bon logiciel part d’au plus quelques programmeurs qui construisent et organisent un équipe de personnes qui teste, nettoie, améliore et s’agrandit pour rejoindre les initiateurs du projet ou même les remplacer. Les vérifications, les tests ou les audits du code ne peuvent pas produire du bon code à partir d’une base médiocre.

Par conséquent, pour les modules que les super-reviewers considèrent comme suffisamment bien gérés, nous favoriserons les responsables qui s’investiront fortement.

Quand un responsable sera considéré comme mauvais ou absent, nous prendrons notre temps pour étudier les candidatures qui nous parviennent et lui trouver un remplaçant afin de réduire notre dépendance vis-à-vis du module en question. Si nous sommes en mesure de patienter le temps de trouver le responsable d’un module important, nous le ferons, mais l’expérience a montré que cela amène presque toujours de sérieux problèmes.

Qu’est-ce que tout cela ne signifie pas ?

Pour continuer à clarifier la situation en utilisant des contre-exemples, voici une liste de choses que nous ne proposons pas :

- Nous n’essayons pas d’arrêter les volontaires et les entreprises qui développent le navigateur basé sur XPFE. Plusieurs entreprises ont ou vont lancer des produits basés sur la suite Mozilla, ou sur un de ses composants. Cependant, nous avons l’intention de nous concentrer sur la séparation des différentes applications telle que cela est défini par la nouvelle architecture.

Par conséquent, il est possible que le navigateur basé sur XPFE soit abandonné assez vite, de sorte que la branche 1.4 contienne seulement une version fonctionnelle. Si assez de contributeurs se manifestent pour maintenir le navigateur basé sur XPFE, mozilla.org considèrera la possibilité de maintenir ce navigateur au-delà de la version 1.4.

Cependant, nous ne sommes pas sûr d’avoir toutes les machines de test et autres ressources nécessaires pour garder ces navigateurs basés sur 2 toolkits différents et les tester correctement.

Nous demandons à ces organisations et aux entreprises qui lancent des produits basés sur la suite Mozilla de nous informer de leurs intentions après avoir pris connaissance de ce nouveau plan de développement.

- Nous ne dévalorisons pas XUL en faveur des interfaces basées sur des toolkits de composants natifs. Nous ne dévalorisons pas non plus Camino, le navigateur basé sur Gecko qui a une interface OS X native. Chaque approche a ses avantages et ses supporters. La communauté Mozilla a choisi les 2 approches (en sortant même une version de Phoenix pour Mac OS X qui marche très bien.)

- Par conséquent, en changeant de navigateur, nous ne laissons pas tomber XUL sur Mac. Nous voulons nous assurer que les programmes et toolkits Mozilla restent utilisables sur toutes les plateformes. De plus, nous avons besoin de tester Gecko autant sur Mac que sur les autres plateformes. En changeant le navigateur par défaut pour Mozilla Firefox, nous fournirons donc des versions de test et des versions finales pour Mac OS X.

- Plusieurs outils importants, qui étaient intégrés au navigateur basé sur XPFE doivent être supportés par le nouveau navigateur sous la forme d’extensions. Il s’agit par exemple de DOM inspector et de Venkman, le débogueur JavaScript.

- Les autres composants intégrés à la suite Mozilla, le calendrier, Chatzilla, et Composer (l’éditeur HTML) ne seront pas non plus mis de côté. Nous ne savons pas encore comment ils vont évoluer, s’ils vont devenir des programmes indépendants (et si c’est le cas, basés sur quel toolkit XUL) ou des extensions à Mozilla Firefox (si c’est le cas, ils devront utiliser le nouveau toolkit XUL.) Mais nous sommes prêts pour les supporter au maximum, en fournissant par exemple des versions quotidiennes et finales pour que la communauté puisse les tester.

La structure des programmes

Commençons cette nouvelle proposition d’architecture en récapitulant ce qui existe déjà et en définissant certains termes.

Il y a actuellement 2 grandes catégories d’applications qui sont conçues sur les technologies Mozilla. La première catégorie est celle des applications englobantes. Elles utilisent le moteur de rendu de Mozilla, mais ont leur propre code pour l’interface utilisateur qui est en-dehors de la vue HTML ou XML. La seconde catégorie est celle des applications toolkits. Elles sont conçues pour se rajouter à Mozilla et pour être multi-plateformes. L’interface utilisateur est définie avec XUL et le rendu se fait par Gecko.

Ces deux catégories d’applications seront capables d’utiliser le Gecko Runtime Environment (GRE) afin de partager une seule installation de Gecko. Elles pourront même partager des profiles, bien que le mécanisme de communication interprocessus qui le permettra ne soit pas encore réalisé (dans la version 1.4 alpha).

Les applications toolkits supporteront également des extensions spécialement conçues pour se rajouter sur l’application afin de fournir des fonctionnalités additionnelles. Dans le cas d’un navigateur, les domaines d’application de ces extensions pourront être par exemple la gestion de la souris, les boutons de navigation, le « DOM inspector » ou le débogueur Javascript.

En outre, nous proposons que certaines applications toolkits puissent elles-mêmes être des extensions, ce qui signifie qu’elle pourront être compilées en tant qu’applications indépendantes ou en tant qu’extensions installées sur d’autre programmes. Par exemple Thunderbird (Mozilla Mail) pourra être exécuté comme une application indépendante ou installé sur Mozilla Firefox en tant qu’extension.

Nous nous attendons à ce que les supporters du navigateur/messagerie intégré demande une extension de ce type, et nous allons travailler pour pouvoir la fournir avant de changer le navigateur par défaut.

L’idée principale est de passer de la suite sur-intégrée à des applications toolkits plus simples, d’enlever les fonctionnalités avancées de la configuration par défaut, mais de fournir des outils puissants qui permettront de construire son propre navigateur en utilisant les différentes extensions. Afin d’éviter une explosion du nombre de versions différentes supportées par mozilla.org, nous fournirons des versions avec toutes les extensions les plus populaires, mais elles seront désactivées par défaut. Vous pourrez bien sûr les activer facilement si vous le souhaitez, ou supprimer celles qui vous semblent inutiles.

Le schéma qui suit devrait rendre cette architecture plus claire.

Ce schéma montre que la messagerie est considérée comme une application (dans un carré) autant que comme une extension (le cercle avec une flèche pointant sur le navigateur.) Les vraies extensions, qui ne sont jamais des applications, sont en haut.

A faire

Ce plan de développement est une proposition. Nous montrons la direction vers laquelle nous pensons que Mozilla doit aller. Pour y arriver, il est impératif que les choses suivantes soient faites :

- Eliminer les #ifdefs MOZ_PHOENIX ajoutés aux fichiers utilisés par les 2 navigateurs.

- Re-synchroniser tous les fichiers « forkés » par Phoenix, afin de bénéficier des corrections de bugs faites sur le navigateur XPFE qui n’ont pas été faites sur Phoenix. La solution est soit de déplacer ces fichiers dans un emplacement partagé, soit de fusionner les corrections mais de continuer avec 2 parties différentes, ou encore de déprécier la partie XPFE, nous n’avons rien décidé pour l’instant. Mais quelques chose doit être fait, et vite (les corrections continueront à être appliquer à la partie XPFE durant la version 1.4).

- S’assurer que les options de compilations mineures (support bas niveau du débogueur Javascript, MathMl, édition de textes enrichis) qui ont pu être enlevées de Phoenix existent dans la nouvelle version.

- Créer ou obtenir des extensions existantes pour :

  • DOM inspector
  • Venkman
  • La barre de navigation du site
  • L’intégration du logiciel de messagerie ( pour écrire un message, etc.)

- Développer Thunderbird qui est basé sur le nouveau toolkit XUL.

- Fournir assez de tinderbox pour couvrir les compilations de l’ancien et du nouveau navigateur pendant la période de transition.

Encore une fois, nous traçons ici seulement les grandes lignes. Le plan détaillé sera développé ultérieurement dans les groupes de discussion ou via Bugzilla.

Nous ne savons pas encore si nous serons capables de passer à Mozilla Firefox pour la version 1.5 finale. Nous vous encourageons à nous envoyer vos commentaires sur le groupe de discussion mozilla.seamonkey.

Calendrier de lancement

Comme cela était expliqué dans le précédent plan de développement, le projet Mozilla suit un plan de lancement trimestriel qui est accès sur le lancement de versions stables contenant de nouvelles fonctionnalités, avec des changements risqués dans la version alpha. Celle-ci est suivie par une période de stabilisation durant la phase bêta, et enfin par une période plus courte où seuls les bugs critiques sont recherchés et résolus.

Beaucoup ont demandé un allongement du temps précédent la version alpha. Mais avec un allongement de celui-ci, nous ne pourrions pas collecter et traiter les remarques et les rapports automatiques de plantage à partir d’un groupe de testeurs assez nombreux. Cependant, nous convenons que la période précédent la version alpha doit être plus longue que celle précédent la version bêta, nous avons donc allongé d’une semaine la phase alpha et réduit d’une semaine la phase bêta. Voici le calendrier de lancement mis à jour :

Ce tableau montre les dates de lancement, avec celles du gel du tronc, de la création de la branche et de la sortie de la version finale (le début d’une version milestone correspond à la date de branchement de la version précédente).

Version Début Gel Branchement Sortie idéale Sortie réelle
1.6 28-Nov-2003 10-Dec-2003 12-Dec-2003 19-Dec-2003 15-Jan-2004
1.7alpha 12-Dec-2003 11-Feb-2004 n/a 16-Feb-2004 23-Feb-2004
1.7beta 16-Feb-2004 10-Mar-2004 n/a 15-Mar-2004 18-Mar-2004
1.7rc1 15-Mar-2004 n/a 09-Apr-2004 23-Apr-2004 21-Apr-2004
1.7rc2 23-Apr-2004 n/a n/a 7-May-2004 17-May-2004
1.7rc3 17-May-2004 n/a n/a 1-Jun-2004 8-June-2004
1.7 1-Jun-2004 n/a n/a 8-Jun-2004 17-June-2004
1.8alpha1 09-Apr-2004 19-May-2004 n/a 21-May-2004 20-May-2004
1.8alpha2 21-May-2004 30-Jun-2004 n/a 2-Jul-2004  ?
1.8beta 2-Jul-2004 04-Aug-2004 n/a 06-Aug-2004  ?
1.8 06-Aug-2004 n/a 27-Aug-2004 8-Sep-2004  ?
1.9a1 27-Aug-2004 6-0ct-2004 n/a 8-Oct-2004  ?

Comme d’habitude, les milestones sont gelées le mardi à 23:59 (fuseau horaire du Pacifique) [Ndt : le mercredi à 07:59 GMT]. Pour plus de détails, allez voir la tinderbox.

Si vous avez l’intention de lancer un produit basé sur Mozilla dont le calendrier de lancement ne s’accordent pas très bien avec les date précédentes, nous vous encourageons à nous contacter (nous garderons secrètes les informations que vous pourriez nous transmettre, et nous prendrons des mesures de protection si nécessaire.)

Que pouvez-vous faire pour nous aider ?

Les programmeurs C et C++ : la tinderbox mesure maintenant l’empreinte mémoire du code, vous pouvez donc commencer à travailler pour la réduire. Résistez à l’attitude naturelle qui consiste à ajouter toujours plus de code. Essayez de supprimer du code, ou de simplifier les portions inutilement compliquées, enlevez les optimisations prématurées et les utilisations inutiles de XPCOM et de ces précurseurs. Si vous voulez ajouter une nouvelle fonctionnalité, assurez-vous de l’avoir inclue dans la bonne bibliothèque, ce qui peut éventuellement nécessiter la création d’une nouvelle bibliothèque.

Chaque ajout aux modules inclus dans les «  versions minimales et optimisées du navigateur » doit être approuvé par les chefs de projet.

Les intégrateurs : nous avons besoin de vous dans Bugzilla, pour marquer les bugs avec des mots clefs tels que embed, footprint,mlk,perf,etc.

Utilisez les nouvelles fonctions de Bugzilla qui permettentdemarquercertains bugs comme bloquant la sortie d’une version (par exemple blocking1.4b ?), et essayez de commenter ce bug pour préciser pourquoi vous considérez que ce bug bloque la sortie d’une version.

Une gestion de projet performante aidera à s’assurer que les programmeurs pourront cibler suffisamment leurs corrections afin de résoudre le maximum de bugs bloquants.

Les responsables de bugs, et particulièrement ceux qui peuvent décharger les responsables assignés par défaut et résoudre ces bugs : essayez de cibler les bugs qui vous sont assignés tout au long du développement de mozilla1.5 et mozilla1.6, en vous basant sur les changements d’architecture du programme et du moteur de rendu. Essayez de désengorger le traitement des bugs, en demandant éventuellement à drivers@mozilla.org si vous ne trouvez personne pour vous aider à résoudre un bug non assigné que vous trouvez important.

Les membres de la communauté : utilisez le marquage des bugs « bloquants » avec parcimonie, et ne changez pas la version visée sans le consentement du responsable du bug. Vous pouvez bien sûr voter pour des bugs pour aider à la gestion des priorités (mais rappelez vous que les patchs sont plus important que les votes). Enfin, essayez d’éviter les commentaires inutiles du style « moi aussi » ou autre dans Bugzilla.

Gestion de projet

Pour guider et pour aider les développeurs qui s’occupent des bugs, pour diminuer les risques et pour aider les projets commerciaux basés sur Mozilla, mozilla.org a créé un groupe de chefs de projet, drivers@mozilla.org.

Les chefs de projets actuels sont :

Articles dans la même rubrique