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

mozilla 1.0 宣言

Brendan Eich

何を

多くの人に次のような質問をされた。「なぜ、Mozilla に 1.0 が必要なのか？ このまま（訳注： 1.0 を特別なマイルストーンとせず）進行して、ベンダーが良いマイルストーンをピックアップするのにまかせるのではいけないのか？」 1.0 には 以下 に列挙されている、いくつかの理由がある。しかし、「Mozilla 1.0」がどのようなものであるかについて、合意しておこう。
  • mozilla.org からリリースされる、Mozilla ブラウザ・アプリケーション・スイートおよびプラットフォームにおける、最初の主要なリビジョンナンバーのマイルストーンリリース (mozilla1.0 ) 。今までのどのリリースよりも高い品質を持ったリリースであり、多大な期待と不安が込められきたバージョンナンバーが 1.0 なので、 その品質に我々の評判がかかっている。
  • 広い意味での様々な API ( XUL 1.0 は API である) の互換性を、2.0 またはそれ以上の番号の主要なリリースまで保ち続ける、という約束。1.0 と 2.0 の間の全てのマイルストーンリリースとトランクの開発は、インターフェースの互換性を堅持するだろう。Mozilla 1.0 は、ハッカー、企業、本の著者たちが、この安定した API の基礎の元に、いそがしく作業を行なっても良い、という青信号になる。
  • cvs.mozilla.org トランクから分岐した、安定で長命のブランチ (MOZILLA_1_0_BRANCH ) 。興味のある人々は、staff@mozilla.org のサポートの元に、このブランチの重大なバグに対して地道な修正作業を行なえるだろう。Mozilla 1.0 のパブリック API で動作する開発の基準線を必要とする人は誰でも 1.0 ブランチに対して作業することができる。

なぜ

多くの企業 が開発した製品を含めた、Mozilla のユーザーは、以下のような特徴を持った、安定し長命なブランチを必要としている：

  • API の互換性の約束（例えば、固定された 組み込み API）
  • ライブラリバージョンの独自性。（それにより、少なくともベンダーが、アップグレードが必要な時期、または古い .dll もしくは .so ファイルを置き換えて新しいバージョンをバンドルする時期がわかるように）
  • 重要なコアモジュール (例えば、XPCOM ) が自立できる、充分なモジュール化。
  • 安定性 -- 許容範囲内の MTBF（訳注： mean time between failures、安定して動作する時間の平均値 ） 、深刻なデータ損失のバグが無い事。
  • 良好なパフォーマンスとメモリ管理。
  • 競合製品を上回る、標準への準拠。
  • 使用しやすさ、正確さ、洗練されている事 (クラッシュに至らないバグや機能不全が多すぎない事）
この必要性は重要だ： もし、mozilla.org が共有するためのブランチ、または各企業や組織がブランチするためのブランチを作成しなかったなら、コードの様々な使用者たちは、情報共有も共同作業も少ない状況のもとに、これを彼ら自身で行ない、結果として品質は低くなるだろう。 それは、我々が望むところではない。

もし mozilla.org が、トランクのアクティブな開発を進行させるのと並行して、統合され、安定な、長命のブランチをホストすれば、Mozilla を改善する手助けをする人が増加し、Mozilla のディストリビューションの恩恵を受ける人が増加し、世界はもっと良い場所になるだろうと、我々は考えている。このブランチは、明らかに、進行、結合、レビュー、そしてテストにおいて、スマッシュを打つような多大な努力を必要とする。我々は、それがどのように管理されるか (そのロードマップがどのようなものになるか) について、まだ確信があるわけではない。 -- しかし、我々はこの必要性を把握しており、計画を立てたいと望んでいて、あなたの意見を歓迎している。

1.0 ブランチに関するノート： 「付加的」なものであるのであれば、大きな変化が 1.0 ブランチに加えられる可能性はないわけではない。しかし、我々は、多くの開発者がトランクに対するハックを続ける事を期待する。そうすれば、トランクソースからビルドされたモジュールは、どの 1.x マイルストーンでも動作するという、固定されたインターフェースによるバイナリ上の互換性というメリットを享受できるからだ。

どのように

この、安定して、長命な、ブランドのブランチは、特定のバグを修正しようとする努力の集中なしにはありえない。バグを特定して、バグリストをゼロに近くする必要がある。完全に時代遅れにならずにこれを達成するためには、少数のマイルストーンをピックアップして、開発者たちに彼らの バグをこのマイルストーンの間に修正するように求める必要がある。もちろん、mozilla1.0 バグを構成する要素について、違う意見を持つ貢献者もいる。標準準拠に関するバグは、1.0 ブランドに値するものの以前に、ほとんどが修正されているべきであると信じている人たちもいる。それは結構だが、このような長いリストを修正するのに必要なマイルストーンの数は推測困難で、現状の修正速度からすると、おそらく非常に多数となるだろう。

全ての Mozilla 開発者に呼びかける。もしあなたが、我々と同じく、世界は mozilla.org からの早期の "1.0" を必要としている、と思うのなら、あなたの努力を、 bug 103705 、すなわち mozilla1.0 トラッキングバグが依存しているバグ群に集中して欲しい。

上記 した制約があるとすれば、我々は、いずれにせよ、安定して、比較的長命 (最低でも1年ぐらい) のブランチを近い将来に仕上げる事が要求されている。このリリースとブランチをどのようなブランド名にするにせよ、安定して有用なリリースを、多くとも 5つのマイルストーン内で、できればそれより少ない数 (だが、おそらく 3つ以下では無理だろう) で仕上げるように計画しなければならない。 そこで、我々は、最も重要なmozilla1.0 のバグフィックスを、0.9.6 から 0.9.9 の 4 つのマイルストーンの間に予定するようにお願いする。

我々が、何回も 言ってきた事だが、我々は新しい機能は要らない。我々が求めているのは、安定性、パフォーマンス、最上の標準準拠、許容範囲内のバグ数、そして良い API だ。

機能にかかるコストは、我々の時間を消費する。直接的にも（機能を移植する人々の機会のコスト。彼らは 1.0 のバグフィックスを手助けできたかも知れない）、間接的にも（ コードレビュアー 、専門のコンサルタント、他の援助者たちの、派生するコスト）。もしあなたが、ある機能を 1.0 に加えたいと思っているなら、あらかじめ、なぜその機能が必要なのかを ドライバー に説明する準備をし、彼らの回答として「その機能に関する作業は、1.0 がブランチするまでサポートできない」と言われるかもしれない、という事を認識しておいていただきたい。

商用の貢献者が、ある機能を 1.0 ブランチの前のマイルストーンに必要とする、という可能性は高いと思うが、我々は、それを CVS ブランチとして、あるいは #ifdefs を経由して、分離させたいと考えている。その機能の導入が無害であると証明されている非常に少数の例外については、フィックスの代わりにチェックインするかも知れない。しかし、我々が強硬路線を取らなければ、早期の "1.0" は達成できないだろう。我々は、全ての貢献者がこの路線に参加するようお願いする。

いつ

スタッフとドライバーたちに尋ねてみたところ、我々の安定して長命な、API の約束されたブランチに "1.0" ブランドを使用するのは、遅いよりは早い方が良いと信じている人が大多数だった。様々なベンダー、本の著者、そしてそのようなブランチを必要としている人々からのフィードバックから判断して、我々は「早い」を次の 6ヶ月以内であると信じている。（訳注： 原文初版は 2001年10月16日付け）

レグレッションのテストと、コードの見直しとともに、 トップクラッシュ と他の重大なバグ（例えば、データの損失）への修正だけがチェックインされるマイルストーンが、 mozilla1.0 のブランドを自信を持って付ける前に必要であると、我々は主張する。従って、1.0 のマイルストーン期間は、ドライバーが承認した変更以外の全てのものに対してツリーがクローズされる期間となるだろう。

以上述べたことを総合すると、トランクが比較的少数のバグ修正以外にはクローズされ、全員がテストに照準をあわせる mozilla1.0 マイルストーンまで、たかだか 0.9.6 から 0.9.9 しかない、という事になる。明らかに、このマイルストーンを仕上げるには、多くの作業が必要であり、その作業をどのように組織化するかについては、より詳細な記述が必要だが、私はそれをこの文書の将来のアップデートに残しておきたい。あなたの意見を歓迎する。

もしうまく行けば、0.9.9 の後は 1.0 のマイルストーンとなるだろう。もし 1.0 が作業につれて後退していくようであれば、バグフィックスに関する我々の 1.0 の定義は壊れた事になる。従って、我々は、継続的にスケジュールと顕著なバグを見直す事になるだろう。追加のマイルストーン (0.9.10) が必要であっても、1.0 が充分近い将来に達成できるのであれば、それも良しとしよう。-- しかし、追加のマイルストーンの数を数えるべきではない。2 つ以上の追加のマイルストーンは存在しないはずだ。さもなければ、繰り返すが、早期の安定したブランチと6ヶ月以内のリリースに集中する、という目標に失敗したことになる。

誰が

我々は、 Mozilla 1.0 トラッキングバグ にリンクされているバグを所有している人すべての助力を必要としている。（しかし、このバグにスパムを加えたり、その依存関係を変更しないでいただきたい。もしこのような事をすると、あなたの bugzilla へのアクセス権が停止されるかもしれない！ 議論には、ニュースグループ を使用すること） このリストは、まだ完全ではない。今後、様々な領域の重要な人々との相談と、あなたのフィードバックによって、更新されるだろう。

何が 1.0 に加えられるかについての最終発言権は、一人の人物、すなわち善かれ悪しかれ わたし にある。-- しかし、正しいことを行なうために、私が権利を委任し、その判断と総意を信頼している、何段階もの人々がいる。委任、判断、総意の第一列は、 スタッフ と ドライバー であり、彼らはさらに、ポークジョッキー 、 レビュアー 、 モジュールオーナー 、バグのアサインを受けた人、QA コンタクト、トリアージャー、そして、コミュニティの他のメンバーに依存している。バグ 103705 は現在（そして一時的に） nobody@mozilla.org にアサインされているが、我々は依存関係にあるバグ群のオーナーを特定中である。あなたが、これらのトラッキングバグのどれかのオーナーになって手助けをしたいと思うなら、私にメールしていただきたい。

あるバグが 1.0 までに修正されているべきであるとあなたが信じているのであれば、それに mozilla1.0 キーワードを付けることによって、ノミネートしていただきたい。そのバグは、アサインされ、1.0 かそれ以前のマイルストーンをターゲットとされるかもしれない。もしドライバーと、関連する 1.0 トラッキングバグのオーナーが、そのバグは 1.0 にとって重要だ、と考えたなら、それは依存関係としてリンクされるだろう。もしリンクされていない、ターゲットされていない、それどころかアサインすらされていないようなバグがあれば、気軽に提案していただいて構わないが、まず以下のことを自問自答していただく事を お願いする。

  • そのバグを修正することは、ウェッブページの作者、Mozilla のディストリビューター、Gecko を組み込んでいる人たち、その他の安定したコードと最小限の固定した API のセットを必要としている人々にとって、重要な事か？
  • 他の 1.0 バグを作業している人たちをわずらわせないような代替案は存在しないか？
  • もし我々がそのバグを修正せず、1.0 にそれが存在したとして、どのような悪いことが生じるのか？
  • そのバグを修正する事の代償として、我々が 1.0 であきらめなければならないものは何か？
  • スラッシュドットと C|net の双方を同時に熟読した上で、このバグは 1.0 の出荷を止めるに値する問題だ、と確実に言えるか？ 我々は、まだ、「いままさに出港しようとしている所だ、これ以上のリスクは負えない」という段階には至っていないので、この質問は、1.0 が間近に迫ったときに、優先順位を付けて、不愉快な驚きを避けるのに役立つだろう。

Mozilla 1.0 が依存するバグ群:

  • API
  • モジュール化
    • 独立したコンポーネントの作成
      • XPCOM
      • JS (ビルドシステム)
      • XPConnect
      • Necko ?
    • 悪い依存関係の修正 (拡張子は必要ないはず)
      • wallet
      • cookie
    • 拡張子のクリーンアップ
  • パッケージ化、バージョニング
    • DLL バージョニング
    • ABI 目録 (サポートされているプラットフォーム x でのツールチェイン・リスト)
  • 標準
    • 将来における互換性の問題 (例えば、PNG、CSS、その他で使用される、単一のガンマコレクションがない）。
    • ウェッブページの作者たちが依存する、広く使用されている標準仕様
  • 安定性
    • トップクラッシュ
    • データロス
    • MTBF の上昇傾向、どんな時も最大に
    • Mac の talkback
  • 使用しやすさ
    • 全てのユーザーインターフェース (UI) が有益なものである事 (キーワード useless-ui でクエリー)。
    • UI の要素に欠損や隠されているものがない事 (サイズ変更できるダイアログがない事)。
    • 元に戻れないような袋小路がない事。
  • パフォーマンス
    • 起動
    • ページのロード
    • 新規のウィンドウ
    • ユーザーインターフェースの反応
  • Footprint （訳注：割り当てられた後、解放されないメモリ領域の大きさ）
    • コード
      • 使用されていないものの削除 (例、viewmanager2)。
      • バーチャルメソッドと XPCOM が必要のない局面で使用されないようにする。
      • 特定部分の削減。
    • データ
      • 恒常的な footprint の削減、リークを除く。
      • リークの修正。
  • セキュリティとプライバシ
  • 正確さ
    • 明確かつ悪性な不具合で、上記のカテゴリに入らないもの全て。
  • 洗練
    • スペリング
    • 使用には支障のない外見上の不具合
    • 醜いものは何でも。ただし、動作していて早期に修正可能なもの
  • デフォルトに設定されている機能
    • MathML
    • DOM Inspector
    • Venkman
  • パーティー （訳注： この項目だけは、Mozilla 1.0 トラッキングバグが、これをブロックしている、とされています。つまり、上記の全てのバグを潰さないと、1.0 完成パーティーが開けない、という事です）