En coulisses

Que se passe-t-il lorsque l'auteur d'une modification nous interpelle : « Eh, mozilla.org ! Prenez ce code s'il vous plaît ! ». L'un des rôles les plus importants de mozilla.org est de définir les critères d'acceptation d'une contribution. Nous devons faire face à de nombreux problèmes. Tout d'abord vient l'appréciation du mérite. Le code est-il bon ? Deuxièmement, est-il sous une licence compatible avec la NPL ? Nous décidâmes de ne pas accepter les contributions non couvertes par une licence compatible avec la NPL. Sinon elles devraient être ventilées dans des répertoires bien distincts, séparés par des murailles, et cela impliquerait de grandes manœuvres d'ordre juridique. Le risque d'erreur augmenterait énormément.

Puisque Mozilla est une base de code très modulaire chacun de ses composants majeurs, par exemple la bibliothèque de gestion des images ou l'analyseur XML, a un « propriétaire » désigné. Il connaît parfaitement le code et fait office d'arbitre lorsque l'on décide d'y inclure ou non une contribution.

De nombreux propriétaires de modules sont des ingénieurs de Netscape mais d'autres sont des volontaires externes. Quand un propriétaire de module effectue des changements (par exemple, ajoutant une API à la bibliothèque de gestion des images), il les expédie à mozilla.org qui les inclura dans les distributions. Si des différents apparaissent entre un contributeur et le propriétaire du module, mozilla.org joue le rôle d'arbitre en établissant l'appel final - toujours conscient que s'il arrête de jouer selon les règles de l'art il sera ignoré et quelqu'un d'autre endossera sa mission.

Mozilla.org devait faire face à la diversité des développeurs. Les méthodes utilisées pour travailler sur le code en interne devaient s'accommoder du Web et rester accessibles pour toutes les plates-formes, dans toutes les zones horaires. Ce fût fait avec le « contrôle d'arborescence » assuré par les outils Bonsai et Tinderbox.

L'outil « Bonsai » honore des requêtes portant sur le contenu d'une archive. Comme aux guichets d'une banque, vous pouvez grâce à lui « déposer dans la chambre forte » du code développé, et voir quels « dépôts » ont été effectués par d'autres participants. En arrière-plan il engendre constamment le code, vérifiant l'arborescence du source et lève un « drapeau rouge » en cas de problème, interdisant les dépôts jusqu'à ce que le problème soit identifié. Il engendre sur simple demande des historiques et la liste des problèmes pris en charge durant une période donnée. Bonsai, tout d'abord utilisé par les développeurs maison de Netscape, fut imposé aux activistes du monde entier œuvrant, qui y accédaient sur mozilla.org grâce à n'importe quel arpenteur Web.

Plus de dix développeurs travaillant simultanément sans outils adéquats mènent à la catastrophe. Un programme nommé « Tinderbox » gère ce travail d'équipe afin d'éviter cela en menant une sorte d'enquête dans l'arborescence des sources. Grâce à lui on connaît toujours l'identité de l'auteur d'un quelconque tronçon de code (il exploite pour cela Bonsai), quelles versions du logiciel fonctionnent ou non (et pourquoi !), et l'état des fichiers utilisables afin d'identifier les sources des défauts.