摘要

  • Mozilla 的规则分别规定模块负责人或同级评审的批准、个人的仓库访问级别、代码落地，以及 Release Drivers 对里程碑和代码树的发布管理。
  • 从评审到发布的凭据应分别保存模块、改动、批准角色、有关时的权限依据、落地修订、分支、发布决定和公开制品；不能把一个“OK”写成 Firefox 必然发布。

一个“同意”，四种不同的事实

“Mozilla 已批准它”这句话听起来完整，却不足以支撑部署、打包或支持决策。它究竟指模块负责人审过补丁，某人取得了仓库权限，改动进入开发分支，改动被选入某个里程碑，还是用户已经可获得某个 Firefox 制品？这些是不同的事实，各有不同的责任人和可核对记录。

模块所有权政策说，模块负责人受托领导一个模块的工作；对代码模块，代码进入该模块需要负责人的 OK。负责人可以指定 peers 共同批准代码；负责人不得审自己的代码，而必须交给 peer 评估。负责人也可以要求修改、拒绝补丁或因临近里程碑推迟评审，并应在有关 bug 中说明理由。争议无法解决时，Module Ownership 的监督路径可以介入。

这是一项局部的技术判断，不是一张通行证。负责人同意某个改动，并不证明作者拥有任何仓库的写入权限，也不决定 Firefox 的哪个渠道何时装入该改动。Mozilla 还明确区分模块负责人和 Bugzilla 组件负责人：后者是报告的默认接收者，前者负责模块方向和代码评审。两种角色可以落在同一个人身上，但角色重合不等于权限融合。

提交权限是针对个人的信任决定

Commit Access Policy 处理的是另一件事：不同仓库需要什么权限才能提交。政策设置了递进的访问级别和不同的担保要求。核心产品访问需要政策所规定的有关模块负责人或 peers、或 Tree Sheriffs 的担保。即使有了该级别，政策仍说明社会性控制可能阻止某人在某些代码树中提交。

这点不能被忽略。权限级别是对一个人可信度和熟悉程度的判断，并非可以带到所有后续环节的豁免。公开流程要求申请人说明所需级别、提供 SSH 公钥、同意要求并取得必要担保，然后才由相关人员核验并开通。担保人还会在初始期间对新提交者的提交承担责任；在既定情形下也可请求撤销权限。

模块负责人与权限机制确有交集：负责人可以按规则为申请背书。但一次有利的代码评审不会自动发放权限；一个已经有权限的人，也不会因此成为所有改动的适格评审者。评审记录回答“这项改动是否适合这个模块”；权限记录回答“这个人能否在规定的仓库边界中操作”。报道不应让前者吞没后者，或让后者冒充前者。

落地不是对用户发布的承诺

代码落地把某项改动固定到具体修订、仓库和分支。这个记录很重要，却不能证明用户会收到它。Firefox 的公开交付指南描述了 firefox-main、firefox-beta 和 firefox-release 三条不同分支，以及 Nightly、Beta 和 Release 三类渠道。它们之间的移动有自己的节奏和条件；指南指出，代码需要先进入 main，才可被 uplift 到 beta。

Release Drivers 的责任又不同。Mozilla 说他们为里程碑发布提供项目管理，指导哪些修复对某个发布重要，并作出一系列代码树管理决定。模块评审可以让一个改动具备进入下一环节的基础，却不能单独选择公开发布的内容。反过来，发布优先级也不重写模块内的技术判断。dot release 依赖足够重要的驱动因素，而不是任何一次早先评审的自动后果。

因此，开发分支中的修订不能写成 Release 渠道承诺；具备 uplift 条件也不等于已经 uplift；讨论过某个里程碑也不等于产生了面向用户的制品。若文章声称“将发布”或“已发布”，就应能展示目标渠道或分支、相应选择决定以及可识别的公开制品。

让每次交接都可核查

对有实质影响的公开说法，最小的评审到发布凭据应先写明稳定的改动标识和所属模块，再写明给出评审的负责人或 peer 角色、公开评审记录及日期。如有必要涉及访问权限，记录适用的级别或授权路径，而不披露不必要的个人信息。随后记录落地修订、仓库和分支。若谈到发布，再补上目标分支或渠道、发布选择证据、制品标识和日期。

凭据也必须清楚自己不能证明什么：不能把评审叫作授权，不能把权限叫作评审，不能把一条修订叫作发布。这不是要求 Mozilla 增加一套手续。恰恰相反，它只是让 Mozilla 已经建立的边界在公开叙述中保持可见，使读者知道哪一项事实已经成立，以及从补丁走到产品还需要哪一次明确决定。

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