要約

  • Mozillaの方針は、モジュールオーナーまたはpeerによる承認、個人のリポジトリアクセス、変更の着地、Release Driversによるマイルストーンとツリーの運用を別のものとしている。
  • 査読からリリースまでの記録は、モジュール、変更、承認した役割、必要ならアクセス根拠、着地したリビジョン、ブランチ、リリース判断、公開成果物を別々に残すべきである。

「承認」の中にある四つの行為

「Mozillaが承認した」という表現は、正しいこともあるが、運用上はほとんど何も決めない。モジュールオーナーがパッチを査読したのか。ある個人に書き込み権限が与えられたのか。変更が開発ブランチに入ったのか。マイルストーンに選ばれたのか。利用者向けFirefoxの成果物が存在するのか。それぞれの問いには、別の担当、別の記録、別の効果がある。

Module Ownershipの方針では、モジュールオーナーはモジュールの作業を委ねられた人であり、コードをそのモジュールへチェックインするにはオーナーのOKが必要とされる。オーナーはコード承認を行えるpeerを指定できる。一方で自分のコードは自ら査読できず、peerに評価を委ねなければならない。変更の要求、パッチの却下、マイルストーンを理由としたレビュー延期も可能だが、理由は関連bugに記すことが求められる。解決しない論争にはModule Ownership側の関与の経路もある。

ここで与えられているのは、特定モジュールと特定変更についての技術的判断である。これは全リポジトリに通用する身分証ではない。OKは、作者がどのリポジトリへ書けるかを示さず、Firefoxの公開チャネルの内容も決めない。MozillaはBugzilla component ownerとmodule ownerも区別する。前者は報告の既定の受取人、後者はコードの方向と査読を担う。同じ人である場合があっても、役割の境界は消えない。

コミットアクセスは個人への信頼判断である

Commit Access Policyが問うのは別のことだ。各リポジトリにコミットするのに、個人はどの権限を必要とするか。方針は段階的なアクセスと、それぞれに必要なvouchingを定める。コア製品のアクセスには、関係するモジュールオーナーまたはpeer、あるいはTree Sheriffsによる所定の保証が必要となる。それでも方針は、社会的な統制によって特定のツリーへのチェックインが妨げられることがあると明記する。

つまり、アクセス水準は後続の全ルールを免除する券ではない。これは一人の個人に対する信頼と熟知の判断である。公開手続は、希望する水準、SSH公開鍵、要件への同意、必要な保証を求め、確認後にアカウントを用意する。保証者は初期期間のコミットにも責任を負い、規定の条件では権限取消しを求めることができる。これは特定の変更がモジュールに適するかという査読判断とは別の統制面である。

モジュールオーナーがアクセス申請の保証に関わることはある。しかし好意的なレビューが自動でアクセスを発行するわけではない。逆にアクセスを持つ人が、到達可能な全変更の適切な査読者になるわけでもない。公開説明は、査読の根拠と個人権限の根拠を別の記録として残さなければならない。

着地は公開リリースの約束ではない

着地は、変更を特定のリビジョン、リポジトリ、ブランチに結び付ける出来事である。それは重要だが、利用者が受け取ることの証明ではない。Firefoxの出荷ガイドは、firefox-main、firefox-beta、firefox-releaseという別のブランチと、Nightly、Beta、Releaseというチャネルを説明する。移動には固有の周期と条件があり、betaへupliftする前にmainへ着地していなければならない。

Release Driversは別の仕事を担う。Mozillaによれば、彼らはマイルストーンリリースのプロジェクト管理を行い、どの修正があるリリースで重要かを案内し、ツリー管理の判断を行う。モジュールの査読は次の受け渡しを可能にしても、公開チャネルに何を入れるかを単独で決めない。dot releaseも、十分に重要なdriverに対応する別の判断であり、過去のOKから自動的に生じるものではない。

受け渡しを検証可能にする

重要な公開主張には、簡潔な査読からリリースまでの記録が必要である。まず変更とモジュールの安定した識別子、次に承認したownerまたはpeerの役割、公開査読の記録と日付を書く。アクセスを論じるなら、不要な個人情報を出さず適用された水準または正規経路を記す。その後に着地したリビジョン、リポジトリ、ブランチを置く。リリースを主張するなら、対象チャネルまたはブランチ、選択の証拠、公開成果物、日付を加える。

この記録は限界も示すべきだ。査読をアクセス許可と呼ばず、アクセスを査読と呼ばず、リビジョンをリリースと呼ばない。これは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