訳者註 ： 翻訳するに当って、細心の注意を払っていません。また、質問も受け付けていません。

原文

Mozilla の開発はどのように動いているのか？

あなたたちが良く知っているように、 mozilla.org は Mozilla のソースコードから一日に何度も "ビルド" を作成する。これらデイリー（あるいはナイトリー）ビルドは、 cvs.mozilla.org サーバーからソースコードを "プル" した結果だ。通常のナイトリービルドは、 CVS "トランク" の "チップ" からプルされる。つまり、これらのビルドは CVS チップに "チェックイン" された殆どの最新の変更を含んでいる。我々は、毎朝開発を停止し、これらのビルドで、昨日の変更をテストし、チェックインが本当にバグを fix しているか、昨日の作業で生じた新しい問題の特定などを行なう。

ほぼ５週間ごとに、 drivers@mozilla.org は、数日間、中等度のリスクをトランクに組み込み、短命のコード "ブランチ" をトランクから作成する作業をおこなう。この "フリーズ" 期間の全てのチェックインは、 drivers@mozilla.org の了承を必要とする。安定したビルドができ、マイルストーンにとって最も重要と考えられる多数のバグの取扱いが終了したら、ブランチが作成された事になる。 コードブランチは、ブランチした時点での、トランクの独立したコピーと考えられる。ブランチが "カット" されると、トランクの開発は再開され、開発者たちはドライバーたちに変更をチェックインする許可を得ずに済むようになる。 drivers@mozilla.org で働いている少数の開発者たちは、マイルストーンのクリティカルなバグを fix しようとし、それをブランチにチェックインしようとする。 この作業の間、大多数の開発者はトランクのチップでの作業に戻る。 ドライバーたちが、そのマイルストーンブランチは公表に耐えるようになった、と満足したら、そのブランチにリリースタグが付けられる。 このタグは、マイルストーンビルドを作成するのに必要な全てのファイルのマーカーである。 タグからビルドが作成され、リリースされ、マイルストーンブランチで作業している少数の人々は、トランクの作業に戻る。これが、 Mozilla トランクとブランチの開発の基礎的な流れである。

これが、商用リリースにどのように関係するか？

ベンダーは、二つの方法、すなわちプライベートまたはパブリックのどちらでも作業できる。各々のプロセスには、利点と欠点がある。

プライベートプロセスでは、ベンダーは cvs.mozilla.org からツリーをプルでき、 密室でこのツリーを作業し、（コードライセンスの要求を満たすように）Mozilla のファイルを変更して、製品をリリースできる。私が思うに、このプロセスによる開発の最大の利点は、ベンダーが、mozilla.org ではなく、彼ら自身の開発プロセスを使用できる事だ。Mozilla コードベースで許されていない変更を行なうことが自由になるのである。この方法には、いくつかの欠点がある。その1、ベンダーは、 tinderbox、 Mozilla ナイトリービルド、そしてコミュニティによるテストなどの mozilla.org のリソースを使うことができない。その2、ベンダーによる変更が、Mozilla トランクとコンパチブルにならないかもしれない。これは、ベンダーにとっては、トランクに行なわれた fix を使用しづらくなる、という事を意味し、 mozilla.org にとっては、ベンダーのツリーで行なわれた fix を使用しづらくなる、という事である。この方法をベンダーが使用するやり方は様々だ。あるものは、この "フォーク" を全て、あるいはできる限りのマイルストーンで行ない、彼らのツリーを Mozilla のツリーと同じものにしようとする努力をしている。これにより、二つのコードベースで修正を共有するのが容易になる。OEone の Penzilla の開発はこの良い例だ。彼らは、早期のマイルストーンでしばらくの間、作業を行ない、 それからその結果をより最近のマイルストーン・コードツリーにマージする。他のベンダーは、一度だけフォークし、コードをラジカルな方向に持っていく。 Active Stage の Komode の開発はこの良い例だ。どちらの方法でも、ベンダーは、製品をリリースするときに、Mozilla ファイルに行なった変更を全て公表しなければならない。フォークが極端で、ベンダーがファイルに行なった変更がラジカルなものであると、好ましい変更を Mozilla に統合することが、非常に困難になり、時には不可能になる。

パブリックプロセスでは、ベンダーはMozilla ツリーに対して変更を行なう。この変更は、 mozilla.org のレビュー、スーパーレビュー、フリーズ期間中の承認を必要とする。変更を追加するのは、Mozilla トランクでもブランチでも良い。いずれにせよ、変更は公開されている cvs.mozilla.org のレポジストリに追加される。Mozilla のマイルストーンブランチは、すでにいくつかの安定作業がブランチに行なわれているので、ベンダーにとって魅力的だ。ブランチから安定した商用リリースを作成しやすくなるのである。 マイルストーンリリースタグのコードを用いて、いくつかのマイナーな変更をローカルで行ない、製品をリリースしているベンダーもいる。 Beonex Communicator が良い例だ。他のベンダーは、多数の変更、あるいは大幅な変更を行なう必要があるので、 mozilla.org がブランチの作業を終えた後でも、マイルストーンブランチで公開の作業を継続する。この方法の一例が、Netscape のNetscape 6.1 における作業だ。 mozilla.org がマイルストーンの作業を終えた後に、Netscape は Mozilla 0.9.2 public CVS branch にチェックインを継続する。このブランチに対する作業は、やがて 0.9.2.1 CVS タグとして結実し、これが Netscape の商用リリースの基礎となる。この開発モデルの第一の大きな利点は、ベンダーによる変更がベンダーのリリース前に入手でき、変更が前向きに （より容易に） ブランチに統合できる点にある。第二の利点は、他のベンダーがそのブランチに加えられた改良を自分のリリースに取り入れることができる、という点である。例えば、 Red Hat は、 0.9.2.1 （Netscape 6.1 に対する Mozilla タグ） からのビルドを、彼らのリリースにバンドルすることができた。このタグからのリリースは、より以前の 0.9.2 マイルストーンに比べて、はるかに安定しており、洗練されていたのである。

で、Netscape はどんな事をしているの？

Netscape は、二番目にあげた、よりパブリックな開発プロセスを継続している。Netscape 社のデベロッパーたちは、Mozilla トランクと、0.9.4 ブランチの双方で作業をするだろう。Netscapeは、 0.9.4 タグをつかみ取って、全ての作業をそれ自身のツリーで見えないように （小さなフォーク） することもできるが、それはMozilla に取って損失となるだろう。もし彼らがプライベートなフォークを選択したら、 mozilla.org が Mozilla ファイルへの変更を他のベンダーやデベロッパーたちの為に 0.9.4 ブランチにマージするのはつらい作業となる。mozilla.org はこれらの変更を反映するように要求されるだろうが、余計な作業を必要とするので、 cvs.mozilla.org には統合されない可能性が高い。主要な商業リリースで動作するプラグイン、あるいはテーマやサイドバーなど他のアドオンを作成したいと考えているデベロッパーは、RedHat や OEone の他にもいるだろう。これらの商用リリースで、Mozilla ベースとマッチした Mozilla タグにアクセスできる事は、プラグインなどの開発を容易にする。

Mozilla ライセンスと開発プロセスは、Mozilla をベースにした製品の作成において、様々なアプローチを可能にしている。 複数のブランチでバグを追跡し、開発を行なうのは難しいかもしれないし、我々のプロセスとツールもこのような開発に際して役に立つように進化しなければならない。 しかし、作業が cvs.mozilla.org で公開された暁には、開発者とベンダーのコミュニティにとって明白な勝利となる。 Netscape は、 Netscape 6.x をリリースする前に、Mozilla コードを安定化させる作業を商業的に必要としている。彼らは現在、作業を可能な限り公開されたブランチで行なっており、また将来もそうするだろう。

他の質問

Mozilla ブランチで行なわれていることに対する理解の一助になるように記述したつもりだ。もし他の質問があれば、遠慮なく投稿してくれたまえ。できうる限りお答えしよう。

--Asa