迅速なリリースのための新たな開発チャンネルとリポジトリ

Mozilla Developer News » Blog Archive » New development channels and repositories for rapid releasesの試訳です。誤訳に注意。



先日、私たちは新たなるFirefoxの開発およびリリースプロセスのためのチャンネルについての更なる詳細を発表しました。私たちはこのプロセスにより、高品質なFirefoxを速いテンポでユーザーに向けて出荷できるようになり、最終的な機能についての長期にわたる徹底的な議論を求めることができると確信しています。

新たなアップデートチャンネルとリポジトリの背景的理由

Firefoxは現在、同じコードリポジトリから生成されるアップデートを含む、3つのアップデートチャンネルを持っています:

  1. Nightly - 毎晩、mozilla-central リポジトリから生成されるビルドです。QAを受けてはいません。
  2. Beta - mozilla-central リポジトリから生成されるビルドですが、ベータユーザーに向けてリリースするに足るとされるQAを受けています。
  3. Release - mozilla-central リポジトリから生成されるビルドですが、何億人ものユーザーに向けてリリースするに足るとされるQAを受けています。

Nightly チャンネルはユーザーへの提供前のテストを受けていないままアップデートされているため、そのチャンネルは危険であることと、大多数のユーザーは安定したFirefoxを望んでいるということを示すために、別のアイコン及び名称("Minefield<訳注:地雷原の意>")を使用しています:
f:id:saneyuki_s:20110409203057p:image
このアプローチによって私たちは上手くやれているものの、現在の構造に基づく複数の問題点があることも感じています:

  1. Betaチャンネルのアップデートの品質への期待は、Nightlyチャンネルのそれに比べて圧倒的に高い。
  2. Betaチャンネルのユーザーも、プレリリース(とはいえ、うまくいっていればちゃんとした)版のFirefoxを使用しているとはわからない。
  3. 上記の#1により、Betaチャンネルへのアップデートに向けた安定化のためにmozilla-centralリポジトリの開発は凍結される。これにより多くのパッチの取り除きが発生し、次のベータ版に更なるリスクを追加することとなる。
  4. サードパーティは、(機能の完成やAPIの凍結、stringの凍結といった)考慮すべき点にマイルストーンがいつ到達するのかを念入りに追いかけなければならない。
  5. 開発者にとっては、mozilla-cetralから最新のアップデートの出荷をいつ行うかに依存する形で、mozilla-central上では開発ツリーのルールが常に変化することとなる。

これらの問題のため、私たちはプロセスの修正を議論しました:
f:id:saneyuki_s:20110409203322p:image

  1. Nightly - 毎晩、mozilla-central リポジトリから生成されるビルドです。QAを受けてはいません。
  2. Aurora - 6週間*1ごとにmozilla-centralと同期する、mozilla-auroraリポジトリから生成されるビルドです。アップデートが提供される前に、6週間を目処にしたわずかなQAが行われます。
  3. Beta - mozilla-betaリポジトリから生成されるビルドです。ベータユーザーに向けてリリースするに足るとされるQAを受けています。
  4. Release - mozilla-releaseリポジトリから生成されるビルドですが、何億人ものユーザーに向けてリリースするに足るとされるQAを受けています。

また、新たな構造では、先ほど述べた問題点は解決します:

  1. Betaチャンネルのアップデートの品質への期待は、Nightlyチャンネルのそれに比べて圧倒的に高い。
    私たちは Auroraチャンネルを作成することによって対処しました。このチャンネルはNightlyよりも高い品質が期待されるものの、Betaほどには期待されません。6週間ごとのAurora周期の始まりには、品質はNightlyチャンネルに近いものとなります。6週間ごとのAurora周期の終わりの品質は、Betaチャンネルに収束させるのに適したものとなるでしょう。
  2. Betaチャンネルのユーザーも、プレリリース(とはいえ、うまくいっていればちゃんとした)版のFirefoxを使用しているとはわからない。
    この問題を解決するために、独立したチャンネルから新しいアイコンと併せて、ブランディングしたビルドを行います。これによりユーザーは、一目で利用している更新チャンネルおよびチャンネルに応じた安定性を期待することができるでしょう。
  3. 上記の#1により、Betaチャンネルへのアップデートに向けた安定化のためにmozilla-centralリポジトリの開発は凍結される。これにより多くのパッチの取り除きが発生し、次のベータ版に更なるリスクを追加することとなる。
    リポジトリごとにチャンネルを分けるモデルを使用することにより、mozilla-centralの開発(およびNightlyチャンネルのアップデート)を凍結することが無くなりました。リリースプロセスによる影響なくFirefoxの開発を継続する一方で、他のリポジトリにて品質の収束を行えます。
  4. サードパーティは、(機能の完成やAPIの凍結、stringの凍結といった)考慮すべき点にマイルストーンがいつ到達するのかを念入りに追いかけなければならない。
    新プロセスでは、どこでいつ、何が起きているのかといったことの多くが、明示的かつ一貫しています。サードパーティはもはや「beta8でAPIが完成し beta9でstringが凍結する」といったことを知る必要はありません。その代わり、私たちは「Auroraチャンネルのアップデートでは新しい en-USのstringが追加されることはありません」や「Betaチャンネルでは拡張機能APIの変更がユーザーに解放されることはないだろう」といった保証が可能になります。これによりサードパーティは正確な計画およびルールとスケジュールの継続が可能となります。
  5. 開発者にとっては、mozilla-cetralから最新のアップデートの出荷をいつ行うかに依存する形で、mozilla-central上では開発ツリーのルールが常に変化することとなる。
    最後に、(チャンネルとして配置される)新しいリポジトリは、開発者が開発にベストを尽くすことを可能にします。開発者は、私たちが特定のリリースに向けてブロッカーとなっているバグの解決にのみ注力しているということを知る必要がなくなります。その代わりに、mozilla-centralツリーのルールを守ってさえいれば、いつでも修正をmozilla-central上に載せることができます。mozilla-auroraリポジトリは異なるルールとなる予定で、同様にmozilla-betaも異なる(より厳格な)ルールとなる予定です。多くの開発者のいら立ちや不快感の緩和の助けとなるように、時間の変化につれて、もしくは前のリリースから次のリリースにかけてリポジトリごとのルールが変更となるということはないでしょう。

リポジトリとチャンネルのシステム

リポジトリとチャンネルのシステムは非常に詳細かつ複雑なものです。多くの開発者は、詳細について関心を払うことはないでしょうし、代わりにmozilla-central上に彼らの施した修正が載るかについてを焦点とするでしょう。もしあなたがこの方式の詳細について関心があるならば、前回投稿された、プロセスについての詳細なドキュメントに目を通してください。ドキュメントでは、リリースの肝心を最もよく扱える方法についての決定を集めています。

フィードバック

大きなMozillaのプロセスの変更に関連して、コミュニティからの質問やコメントには励まされています。質問に最適な場所としてはmozilla-dev-planningニュースグループを挙げておきます。そこでは既にいくつかの大きな議論が行われていますので、あなたの疑問に対する回答が既になされていないか過去のスレッドを参照してください。

フィードバックおよびプロセスの詳細なドキュメントの変更は、GitHub上でのpullリクエストによって直接送信することができます。プロセスのドキュメントが既に行った繰り返しを見るために履歴の一覧を見ることもできます。

最後に、私は詳細のドキュメント中の多くの子細について理解しており、時々、その内容について誰かに直接説明することも可能です。いかなるコミュニティのメンバーの質問またはコメントも、メールまたはIRC(LegNeato on irc.mozilla.org)経由で受け付けております。

*1:Firefox5のためのステップが6週間ごとではない理由については、[http://mozilla.github.com/process-releases/draft/development_specifics/:title=プロセスの詳細なドキュメント]を参照してください。