Résumé

  • Les textes de Mozilla distinguent l’accord d’un responsable ou pair de module, le niveau d’accès individuel à un dépôt, l’intégration d’une modification et le travail des Release Drivers pour les jalons et les arbres.
  • Un reçu de revue à livraison devrait conserver le module, la modification, le rôle qui l’a approuvée, le fondement d’accès s’il est pertinent, la révision intégrée, la branche, la décision de livraison et l’artefact, au lieu de transformer un seul « OK » en promesse de Firefox.

Un même mot pour des décisions différentes

Dire que « Mozilla a approuvé » une modification laisse une question essentielle sans réponse. Parle-t-on d’une revue technique du module, d’un droit personnel d’écrire dans un dépôt, d’une intégration dans une branche de développement, d’une sélection pour un jalon, ou d’un artefact Firefox disponible pour les utilisateurs? La formule est commode, mais elle peut déplacer l’autorité d’une étape à une autre sans produire la preuve de cette nouvelle étape.

La politique de propriété des modules attribue la direction d’un module à son responsable. Son accord est requis pour intégrer du code dans ce module. Mozilla permet aussi au responsable de désigner des pairs capables d’approuver du code. Le responsable ne peut pas examiner son propre code: il doit en confier l’évaluation à un pair. Il peut demander des changements, refuser une proposition ou reporter une revue, en expliquant ce choix dans le bug concerné. La règle définit une responsabilité de jugement technique localisée; elle ne crée pas un passeport général pour les dépôts ni un calendrier de produit.

Cette précision protège également l’auteur de la revue. L’accord d’un pair ne doit pas être gonflé en mandat pour toutes les branches, tous les dépôts ou toutes les versions. De même, l’existence d’un accès technique ne peut servir de substitut à l’examen du module. Mozilla sépare même le propriétaire d’un composant Bugzilla du responsable de module: le premier reçoit par défaut les rapports, tandis que le second dirige le code et sa revue. Les personnes peuvent coïncider; les fonctions, elles, restent distinctes.

L’accès est une décision de confiance sur une personne

La politique d’accès de commit répond à une autre question: quelles permissions faut-il pour écrire dans les différents dépôts? Elle prévoit plusieurs niveaux d’accès, avec des exigences de vouching différentes. Pour l’accès au produit central, des responsables ou pairs de module, ou des Tree Sheriffs, doivent fournir les garanties prévues. Cette permission permet d’écrire dans certaines arborescences importantes, mais Mozilla précise elle-même que des contrôles sociaux peuvent encore empêcher une personne d’écrire dans certaines d’entre elles.

Le point est décisif. L’accès est une décision de confiance et de familiarité concernant un individu; il n’efface pas les contrôles qui s’appliquent à une modification précise. La procédure publique demande le niveau souhaité, une clé SSH, l’accord avec les exigences et les soutiens nécessaires avant la création du compte. Les garants assument aussi une responsabilité initiale pour les commits de la personne. Ce sont les attributs d’une permission personnelle, non la conclusion qu’un changement déterminé est techniquement acceptable ou commercialement livré.

Un responsable de module peut participer au mécanisme de vouching. Cela ne transforme pas chaque accord de revue en attribution automatique d’accès. Réciproquement, une personne disposant d’un niveau d’accès n’est pas, de ce fait, le pair approprié pour chaque module. Une bonne information publique doit retenir séparément le chemin de revue et le fondement de la permission, sans exposer inutilement des données personnelles.

Une intégration ne promet pas une version publique

L’intégration associe une modification à une révision, un dépôt et une branche. C’est une information importante, mais elle ne dit pas encore qu’un utilisateur de Firefox la recevra. La documentation de livraison présente un modèle de train avec firefox-main, firefox-beta et firefox-release, ainsi que les canaux Nightly, Beta et Release. Le passage d’un niveau à l’autre suit son propre rythme et ses propres conditions; le guide indique notamment qu’un code doit d’abord être intégré à main avant d’être uplifté vers beta.

Mozilla donne aux Release Drivers un rôle différent: ils assurent la gestion des jalons, signalent les corrections importantes pour une version et prennent des décisions de gestion d’arbre. L’accord technique d’un module peut ouvrir un handoff, mais il ne décide pas seul du contenu d’un canal public. À l’inverse, une priorité de livraison ne réécrit pas le jugement technique qui a permis au changement d’avancer. Les dot releases montrent cette séparation: une correction importante peut motiver une livraison intermédiaire, mais ce n’est pas la conséquence automatique d’une revue antérieure.

Conserver la preuve de chaque handoff

Pour une affirmation conséquente, un reçu compact doit commencer par l’identité stable du changement et du module. Il doit citer le rôle de responsable ou de pair, l’échange de revue public et sa date. Si l’accès est invoqué, il doit identifier le niveau ou la voie autorisée pertinente. Viennent ensuite la révision intégrée, le dépôt et la branche. Une affirmation de livraison doit enfin indiquer le canal ou la branche cible, la décision correspondante, l’artefact public et sa date.

Le reçu doit également dire où s’arrête la preuve. Il ne doit pas appeler une revue une autorisation d’accès, ni appeler une permission une revue, ni présenter une révision comme une livraison. Ce n’est pas imposer une nouvelle procédure à Mozilla. C’est rendre lisible la séparation que ses propres règles ont déjà installée, afin que le lecteur sache quel fait est établi et quelle décision manquerait encore pour passer d’un patch à un produit.

Sources

  1. Mozilla Modules and Module Owners
  2. Mozilla Commit Access Policy
  3. Becoming A Mozilla Committer
  4. Mozilla Roles and Leadership
  5. Pocket Guide: Shipping Firefox
  6. Lu Heng, The Multi-Stakeholder Mirage
  7. Lu Heng, Running-Code Primacy