Summary

  • Mozilla’s published policies distinguish module-owner or peer approval, an individual’s repository-access level, the act of landing a change and Release Drivers’ separate release and tree-management work.
  • A review-to-release receipt should name the module, approved change, approving role, access basis where relevant, landing record, target branch or channel, release decision and artifact instead of turning one “OK” into a claim that Firefox will ship it.

One small word, four different acts

“Mozilla approved it” can sound complete while saying almost nothing a contributor, downstream distributor or security team needs to know. Was the statement about a module owner’s review of a patch? Did an individual receive access to a repository? Did a change land in a development tree? Was it selected for a milestone? Or does a public Firefox artifact actually exist?

Mozilla does not describe those questions as one authority. Its module-ownership policy gives a code module an owner or peers who are responsible for directing work there. Its commit-access policy separately assigns repository permissions to people. Its roles guidance gives Release Drivers milestone-release and tree-management responsibilities. Firefox’s public shipping documentation then describes distinct branches and channels moving on a release train. The system is not unintelligible. The failure begins when an observer turns every one of those bounded records into a single undifferentiated approval.

This is more than terminological hygiene. A reader who mistakes review for access may believe that a technical judgement grants a person broad repository authority. A reader who mistakes access for landing may believe that a credential proves a particular change was admitted. A reader who mistakes a landed revision for release selection may build an operational plan around code that is not in the relevant channel. Each conclusion borrows evidence from a later or different surface.

Module approval is a judgement about a module

Mozilla says that a module owner is the person to whom leadership of a module’s work has been delegated. For a code module, an owner’s OK is required to check code into that module. That duty is deliberately practical: owners are expected to care about what enters, respond to submissions and understand the work well enough to assess contributions. It is not an ornamental title attached after the fact.

The policy also avoids turning one person into an unchecked gate. Owners may designate peers who can approve code. An owner must hand evaluation of their own code to a peer; an owner cannot review their own code. When there is no owner, a peer’s OK can be sufficient. And an owner may decline a patch, request changes or defer review for an upcoming milestone, while being asked to describe the reason in the relevant bug. If a controversy cannot be resolved, the Module Ownership oversight route can become involved.

Those details tell us the scope of the word OK. It is a review and direction judgement concerning a specified module and a specified contribution. It is not a certificate that the contributor holds repository credentials. It does not give a reviewer unilateral control over every tree. It does not establish that a patch is in a channel, has passed every later control or is part of a public Firefox build. The distinction protects both sides: it prevents a reviewer’s judgement from being inflated into a platform-wide mandate, and it prevents an access credential from being misrepresented as a substitute for technical review.

Mozilla’s own separation of a module owner from a Bugzilla component owner reinforces the point. A component owner is the default recipient for reports; a module owner is responsible for direction and code review. Those roles can coincide, but often do not. A bug’s inbox, a technical review, a repository permission and a release decision have different jobs even when the same person happens to appear in more than one record.

Commit access is an individual trust decision

Mozilla’s Commit Access Policy is direct about its purpose: it states the permissions required to commit to different repositories. It provides escalating access levels. General access and core-product access have different voucher requirements. Core-product access allows a person to check in to specified trees from which executable code may become part of core products, but the policy still notes that social controls may prevent a person from checking in to certain trees.

That last qualification matters. An access level is not a portable exemption from the rest of the project’s controls. It is a trust and familiarity judgement about an individual under a published access regime. The public procedure likewise asks an applicant to specify the desired level, supply the required materials and obtain vouchers before a request is checked and provisioned. Vouchers take responsibility for a new committer’s check-ins during the initial period; access can also be revoked in described circumstances.

The connection with module ownership is real but narrow. A current module owner may be a voucher for a stated access level. That does not make every owner’s patch OK an automatically issued access credential, and it does not make every person with access the reviewer for every change they can technically reach. The two systems address different risk questions. Review asks whether a particular change belongs in a module. Access asks whether a person may operate within a defined repository permission boundary.

A sound report should preserve both, rather than use a named reviewer to imply an unnamed personal grant or use a personal grant to imply review.

Landing is not a public release promise

A landing is its own event. It joins a change to a specific repository and branch at a point in time. That record may be important, but it is not the same as the later decision to ship the code through a particular Firefox channel. The release-train guide describes separate firefox-main, firefox-beta and firefox-release branches, corresponding to Nightly, Beta and Release flows. Movement between them has its own cadence and conditions; the guide notes that new work must land on main before it can be uplifted to beta.

That architecture makes a familiar shortcut unsafe. A change on a development branch is not a statement about the release channel. A change eligible for uplift is not proof that it was selected. A fix discussed for a milestone is not a signed promise to users. Firefox’s shipping guide further describes dot releases as a response to sufficiently important drivers, which is another decision surface rather than an automatic consequence of an earlier review.

Mozilla’s roles page is equally clear about the division of labour. Module owners approve patches or resolve conflicts within their area. Release Drivers provide project management for milestone releases, guide developers on fixes important to a release and make a range of tree-management decisions. A module owner’s technical review can make a change eligible for the next handoff. It cannot, by itself, declare that a release should absorb that change. Conversely, a release driver’s prioritisation does not rewrite the module’s technical judgement.

Make the handoffs inspectable

For a consequential public claim, the record should carry a compact review-to-release receipt. Start with the stable change or bug identity and the module concerned. Record the owner or peer role that supplied the review, the date and the relevant public review discussion. If access is part of the claim, record the applicable level or authorised pathway without publishing unnecessary personal material. Then record the landing revision, repository and branch. Finally, where a release statement is made, add the target branch or channel, release-selection evidence, artifact identifier and date.

The receipt should be just as explicit about its limits. It should not call a review a grant. It should not call access a review. It should not call a revision a user-visible shipment. Where evidence of a branch move, release decision or artifact is absent, the public statement should stop at the last supported handoff. That restraint is a service to readers, not a verdict on the people involved.

The aim is not to impose a new Mozilla procedure. Mozilla already has different policies for different surfaces because the risks are different. The editorial task is to stop flattening that design. Authority is most legible when every record says what it proves, what it does not prove, and which next decision would be required to move from a patch to a product.

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