メインコンテンツへスキップ

Mozilla 開発ロードマップ

Brendan Eich

Mozilla 開発ロードマップへようこそ。このドキュメントは、Mozilla プロジェクトがたどってきた道のりを簡単に述べたあと、今どこに向かっているのかを詳しく説明します。ここでは、鍵となる「ロードルール」と、進行中の Mozilla ブラウザソース・マイルストーンリリース のスケジュールを提案します。このマイルストーンリリースからは、誰でも商用その他の製品をビルドすることができます。また、Mozilla プラットフォーム がどのように進化するべきかについても、運営上のあるいは「リリースプロセス」の視点から、同じようにヒントを示します。

背景

オリジナルのロードマップ には、次のものを使って Mozilla プロジェクトを組み直すという、1998 年 10 月の重大な決定が記録されています。その内容は、新しいレイアウトエンジン （現在は Gecko と呼ばれています）、クロスプラットフォーム（XP）のフロントエンド（ XPFE : XP ツールキット でビルドされる エディタ や メール／ニュース などの XP アプリケーション ）、スクリプタブルコンポーネントアーキテクチャ（ XPCOM と XPConnect ）でした。

以前のロードマップ は、Netscape 6 のリリースを経て、その先、Mozilla 1.0 マイルストーン リリースという目標へ向かう Mozilla の道筋を図解していました。その更新版で、私は「Mozilla にはパフォーマンス、安定性、正確性が必要」で、特別新しい機能は必要ない と書きました。2001 年になる直前、私は、有益かつ適切な（コミュニティによって限定された）機能拡張はいつでも歓迎ですが、それが提供されるには 1.0 のハックを手伝ってくれるだろう貢献者たちには十分な機会（時間）がない、と書きました。しかし、2001 年の秋までに、Mozilla 1.0 宣言 で書いた通り、機能拡張に費やす機会（時間）は、1.0 のためではない作業が、予定通りに 1.0 マイルストーンの開発が進むのを脅かす事態にまで達していました。

このロードマップの更新版では、マイルストーンのスケジュールを 2002 年の夏に合わせました。そして Mozilla 1.0 がリリースされました。

ツリーマネジメント

これは、ツリー管理における最新の予定をイメージしたものです。

ツリーマネジメント略図

2001 年の 5 週間単位というマイルストーンサイクルから離脱して、メジャーマイルストーンは四半期もしくは 13 週間ごとに届けられます。そして、安定性を求めない開発をするため、6 週間の「アルファ版」マイルストーンが始まります。これに、より危険度の低いバグを修正するための、4 週間の「ベータ版」マイルストーンが続きます。ここでは、特にコードを再安定化させるための「アルファ版」作業の後始末が目標とされます。最後に、2 〜 3 週間が「リリース」期間で、ドライバー（プロジェクト運営）に認可された作業のみおこない、マイルストーンを完了します。これは、四半期ごとに不定期のホリデーウィークを取るのにも十分ゆったりとしたスケジュールです。これによって、過去 2 年間 12 月に私たちが経験した「時間と人の不足」を回避することになればと願っています。

どのマイルストーンもリリースして自動クラッシュレポート（「トークバック」）を集めるために終わります。私たちは、このフィードバックが集められ、遅くとも 5 〜 6 週間のうちに反映されるべきだと、この数年の経験から信じています。それらの「アルファ版」や「ベータ版」マイルストーンはリリース準備のための数日のツリーを閉じる作業以上必要としないことを望んでいます。「アルファ版」や「ベータ版」はユーザがテスト以外の目的で使用することは勧めるつもりはないので、結果がどうなろうともあらかじめ予定したスケジュールでリリースを提供することを望みます。繰り返しますが、四半期に 1 度のメジャーリリース（例えば 1.3）は、製品として価値あるブランチ・ポイントとなります。

したがって、Mozilla コミュニティのリズムがマッチすることが望まれます。少なくとも 0.9.1 以降をだらだらとしたフリーズとリリースのためのバグを絞り出す前のブランチと共に観察した結果が、「アルファ版」「ベータ版」の奇数偶数パターンという結果になったように見えます。

最後に、ブランチを数える時のリリースのナンバリングは、最初の 1 がトランク・バージョンを示すように、合理化されています。したがって、1.0.2 のブランチのブランチが上の絵に記述されています。1.0 の長いスパンのブランチは、Mozilla 1.0 宣言の 理論的根拠 によって、トランクにも相応しいバグの修正という保守開発が続けられるべきです。

興味のある人たちは、drivers@mozilla.org のサポートを受けて、このブランチの重大なバグに対して地道な修正作業に取り組むことができます。Mozilla 1.0 の公開 API で動作する開発の基準線を必要とする人は誰でも、1.0 ブランチに対して作業することができます。

ここでは、それぞれのマイルストーンについて、トランクのフリーズ、ブランチ作成、マイルストーンリリースの予定日を分けて表にしてあります。（マイルストーンの開始日は、前のマイルストーンのブランチ日です）

マイルストーン開始フリーズブランチリリース（目標）リリース（実際）
1.2 アルファ版2002. 8. 29. 4未定義9. 69. 11
1.2 ベータ版9. 610. 9未定義10. 1110. 16
1.210. 1110. 3011. 111. 811. 26
1.3 アルファ版11. 112. 4未定義12. 612. 13
1.3 ベータ版12. 62003. 1. 22未定義1. 242. 10
1.31. 242. 122. 142. 213. 13
1.4 アルファ版2. 143. 26未定義3. 28？
1.4 ベータ版3. 264. 23未定義4. 25？
1.44. 255. 145. 165. 21？

通例として、マイルストーンのフリーズ時刻は、大平洋標準時の水曜日午後 11 時 59 分です（ Tinderbox のページにある告知をご覧ください）。フリーズ期間には、みなさんが日々のビルドをブランチの価値のあるものとして適合させようとするように、「このマイルストーンで修正が必要」と考えられるバグや、一般的に土壇場でのリグレッションだけがトランク上で修正されます。リリース スタッフ はマイルストーンブランチを作り、早くても次の水曜日に予定されるリリースに先立ち、週末にかけてさらに集中的な品質保証を行います。

リリースが遅れないように、そしてマイルストーンブランチの寿命を延ばしてブランチとトランクの間で作業者を分割させることを避けるように試み、時に失敗してきました。かつての困難があるにもかかわらず、私たちはフリーズに続いて水曜日までにリリースを試みます。そしてスリップを早めるような余分な仕事を吸収する小さなマイルストーンを使います。そのため、水曜日までに修正されないクリティカルでないバグは、次の Mozilla マイルストーンを目標に、できる限り早く修正されるべきです。

ドライバー がこれまでのロードマッププランへの変更を提案した理由は、「より明解な」マイルストーンナンバーを使用するとともに、0.9.1 以降観察された偶数・奇数安定化パターンと終盤戦のスケジュールにマッチさせ、そしてカレンダー上の季節や業務四半期にマッチさせるためです（春分から 1.1 アルファ版 のトランクが開かれるまで 1 週間だけズレを伴います）。あなたが Mozilla ベースの製品をリリースする計画を持っていて、そのスケジュールが上記のマイルストーンに合わないなら、あなたの フィードバック を歓迎します（機密情報は遵守します。必要なら機密保持契約書にサインします）。

協力するには

Mozilla 組み込み制作者 : embed / footprint / mlk / perf / mozilla1.0.1 / mozilla1.1 そのほかの適切なキーワードをつけて Bugzilla に入力してください。Mozilla プロジェクトマネージメント は、バグがその修正に取り組むことのできるハッカーにアサインされ、できるだけ多くのマイルストーンキーワード指定を満足させるようにお手伝いします。

バグ担当者 や、特に、Futured にされたバグやターゲット指定されていないバグを任命されている担当者から受け継いで修正できる協力者 : あなたにアサインされたバグのターゲットを Mozilla 1.0 宣言を基準にして mozilla1.1 や mozilla1.2 マイルストーンの先に回してください。それから、バグを協力者に引き継いでください。もし、Futured にしたバグや、あなたがすぐに修正すべきと考えているのにターゲット指定のないバグの修正を引き受けてくれる人が誰も見つからなければ、drivers@mozilla.org に問い合わせてください。

コミュニティメンバー : mozilla1.x マイルストーンキーワードを指定するシステムを賢明に使ってください。それから、他の人のバグのターゲットマイルストーンを担当者の承諾なしに変更しないでください。これらのキーワード指定／タ−ゲットマイルストーン処理のシステムは Mozilla 1.0 以降も続けられ、バグ担当者の優先順位決定の判断を手助けします。もちろん、いつも通りバグに投票して優先順位付けに役立てても構いません（しかし、パッチの作成が投票に勝る、という事を忘れないで下さい。また、主張はバグシステムの外でやってください）。

コードレビュー

mozilla.org は Mozilla コードベースの大部分へのチェックインを是正するために全面的な コードレビュー の要求を継続しています。Mozilla コードレビューワのドキュメントは、モジュールオーナーによる別のポリシーをもつ cvs.mozilla.org でホストされているコードの範囲と、この「スーパーレビュー」と呼ぶコードレビューが必要なコードの範囲を 区別 します。mozilla.org によってホストされているすべてのコードには積極的なオーナーシップが必要です。貢献者が「cvs commit」を打ち込む前に、モジュールオーナーによる変更のレビューが求められるからです。

デザインレビューはコードレビューより明らかに大切なはずです！ 設計上の疑問や問題を発言するには porkjockeysメーリングリスト（ ニュースゲートウェイ もあります）を使ってください。

プロジェクトマネジメント

協力を必要としているバグに対してタイムリーな形で開発者をふりむけるため、リスクを減らすため、そして Mozilla をベースとした商用製品のリリース管理を援助するために mozilla.org はプロジェクトマネージャ drivers@mozilla.org のグループを作りました。

現在のドライバーは :

遠くない未来、1.0 以降の Mozilla プロジェクトの未来についての考えに基づいてこのロードマップを更新することを望みます。明らかに、Mozilla 1.0 から追い払われたバグの修正、アーキテクチャの変更、新しいコードは、1.1 アルファ版 に取り入れられることが望まれます。Mozilla は、標準でビルトインされているブラウザ、メール／ニュース、エディタ、ChatZilla といったスイートより多くのアプリケーションのためサポートだけではなく、「Mozilla プラットフォーム」の側のサポートを必要としています。私も Mozilla 技術と革新者が優位な品質改善をおこなえることを望みます（例えば、何か Intertwingle のように）。Web 上、ファイルシステムの中、アプリケーションのデータフォーマットの形式、その他どこでもデータが存在する場所において、その情報を、閲覧し、整理し、処理する方法に関する改善です。1.0 の後も開発は続きます - 今後の動向に注目してください。