Zusammenfassung

  • Mozillas Regeln unterscheiden die Freigabe durch einen Modulverantwortlichen oder Peer, den persönlichen Repository-Zugangslevel, das Landen einer Änderung und die Arbeit der Release Drivers an Meilensteinen und Bäumen.
  • Ein Nachweis von der Prüfung bis zum Release sollte Modul, Änderung, prüfende Rolle, gegebenenfalls Zugangsgrundlage, gelandete Revision, Branch, Releaseentscheidung und öffentliches Artefakt getrennt festhalten.

Vier Handlungen hinter „genehmigt“

„Mozilla hat es genehmigt“ kann zutreffen und dennoch für Betrieb, Distribution oder Support zu wenig sagen. Bezeichnet der Satz die Prüfung eines Patches im Modul, die Zugangsdaten einer Person, ein Landing in einem Entwicklungsbranch, die Auswahl für einen Meilenstein oder ein bereits verfügbares Firefox-Artefakt? Für jede Aussage gibt es andere Verantwortliche, andere Aufzeichnungen und andere Folgen.

Die Module-Ownership-Policy überträgt einem Modulverantwortlichen die Leitung der Arbeit eines Moduls. Bei Code ist dessen OK erforderlich, damit Code in das Modul eingecheckt wird. Verantwortliche können Peers benennen, die ebenfalls Code genehmigen dürfen. Den eigenen Code müssen sie jedoch einem Peer zur Bewertung überlassen. Sie können Änderungen verlangen, einen Patch ablehnen oder eine Prüfung verschieben und sollen den Grund im betreffenden Bug erläutern. Bei ungelösten Kontroversen gibt es einen Eskalationsweg über Module Ownership.

Das ist ein begrenztes technisches Urteil, kein allgemeiner Repository-Ausweis und keine Entscheidung über den Inhalt einer Firefox-Version. Mozilla trennt auch die Rolle eines Modulverantwortlichen von der eines Bugzilla-Component-Owners: Der eine verantwortet Richtung und Codeprüfung, der andere ist standardmäßig Empfänger eingehender Berichte. Personen können identisch sein; die Funktionen bleiben es nicht.

Commit-Zugang ist eine Vertrauensentscheidung über eine Person

Die Commit Access Policy beantwortet eine andere Frage: Welche Berechtigungen benötigt jemand, um in unterschiedliche Repositories zu committen? Sie definiert gestufte Zugänge mit verschiedenen Vouching-Anforderungen. Für Core-Product-Zugang gelten die vorgesehenen Bürgschaften relevanter Modulverantwortlicher oder Peers beziehungsweise Tree Sheriffs. Trotzdem hält die Policy fest, dass soziale Kontrollen eine Person daran hindern können, in bestimmte Bäume einzuchecken.

Ein Zugangslevel ist daher kein übertragbarer Verzicht auf die übrigen Regeln. Er ist eine Entscheidung über Vertrauen und Vertrautheit mit einer einzelnen Person. Das öffentliche Verfahren verlangt den gewünschten Level, einen SSH-Schlüssel, die Zustimmung zu den Anforderungen und die nötigen Bürgschaften, bevor der Antrag geprüft und das Konto eingerichtet wird. Die Bürgen tragen in einer Anfangszeit Verantwortung für die Commits und können unter den beschriebenen Umständen einen Widerruf verlangen. Damit ist nicht beantwortet, ob eine konkrete Änderung in ein Modul gehört.

Ein Modulverantwortlicher kann einen Zugangs-Antrag unterstützen. Daraus wird aber nicht aus jedem positiven Review automatisch eine Berechtigung. Umgekehrt wird eine Person mit Zugang nicht zur zuständigen Prüferin jeder Änderung, die sie technisch erreichen könnte. Prüfpfad und Zugangsgrundlage sind in einer belastbaren öffentlichen Darstellung getrennte Tatsachen.

Ein Landing ist kein Lieferungsversprechen

Ein Landing verknüpft eine Änderung mit einer Revision, einem Repository und einem Branch. Das ist relevante Evidenz, beweist aber nicht die Verfügbarkeit für Nutzer. Der Firefox-Leitfaden beschreibt firefox-main, firefox-beta und firefox-release sowie die Kanäle Nightly, Beta und Release. Der Übergang folgt eigenen Takten und Bedingungen; vor einem Uplift nach beta muss Code zunächst in main gelandet sein.

Release Drivers haben eine andere Aufgabe: Projektmanagement für Meilenstein-Releases, Hinweise zu wichtigen Fixes und Entscheidungen über die Baumverwaltung. Ein Modulreview kann die nächste Übergabe ermöglichen, wählt aber nicht allein den Inhalt eines öffentlichen Kanals. Auch eine Releasepriorität schreibt das technische Urteil des Moduls nicht um. Dot Releases hängen von einem ausreichend wichtigen Treiber ab, nicht automatisch von einem früheren OK.

Übergaben überprüfbar halten

Eine folgenreiche öffentliche Behauptung sollte mit stabiler Kennung von Änderung und Modul beginnen. Sie sollte die prüfende Owner- oder Peer-Rolle, den öffentlichen Review und dessen Datum nennen. Wird Zugang behauptet, gehört der einschlägige Level oder autorisierte Weg hinein, ohne unnötige Personendaten zu veröffentlichen. Danach folgen gelandete Revision, Repository und Branch. Eine Releaseaussage benötigt schließlich Zielkanal oder -branch, Selektionsnachweis, öffentliches Artefakt und Datum.

Der Nachweis muss auch seine Grenze benennen: Review ist keine Zugangserteilung, Zugang kein Review und eine Revision kein Release. Das ist keine neue Mozilla-Vorschrift. Es macht nur die Trennung sichtbar, die Mozillas Regeln bereits vorsehen, und zeigt Lesern, welcher nächste Entscheid noch nötig wäre, bevor aus einem Patch ein Produkt wird.

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