Mozillaのパッチを書いて採用されるまで

Mozilla(Firefox/Thunderbird)はオープンソースのソフトウェアです。 そのため、自分でコードが書けるなら、バグを修正したり、機能追加ができます。 ここでは、Windowsでの環境作り、ソースの取得方法と、 パッチの書き方、パッチの採用までの流れを紹介します。

Mozillaのソースコードの取得、ビルドには様々なツールが必要です。 ここでは、VC++でビルドするものとして、話をすすめます。 ただし、無料のVisual Studio Expressではここで紹介する方法ではビルドできないかもしれません。

また、Geckoのバージョンによって、ビルドに必要なVCのバージョンが異なります。 詳しくはオフィシャルのドキュメントの一覧表を参照してください。

残念ながら私はMinGWでビルドしたこと(できたこと)がありません。 また、Mozilla Foundationの方針としてもMinGWはオプションであって、 VC++が標準であるという扱いなので注意してください。 個人的な意見ですが、Mozillaの開発環境としてはMinGWは適切では無いと思います。

それでは、まずは以下の物をシステムにインストールしてください。

Visual C++がインストールできたら、VS_COMNTOOLLS_FOR_MOZの環境変数を作成し、vsvars32.batがあるパスを登録してください。 例えば、Visual Studio 2005 Professionalの場合、 C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\ を指定します。

Cygwinがインストールできたら、Windowsの環境変数を修正して、Cygwinのプログラムが いつでもコマンドプロンプトから使える様にしておきます。 具体的にはインストールパス\binにパスを通します。 ここでは、デフォルトのインストールパスである、c:\cygwinの場合について解説記述しています。

FirefoxやThunderbirdのインストーラをビルドする場合は、CygwinのPerlでなくてはいけません(少なくとも1.5までは。2.0以降は不明)。 Active Perlではエラーが出て、ビルドできないので注意してください。

環境が作れたら、CVSからソースコードを取得します。 ここでは、取得したソースコードをc:\mozilla-src\に保存するものとします。 以下のバッチファイルを作成してmozilla/client.mkを取得します。

set SRCDRV=c
set SRCDIR=mozilla-src
%SRCDRV%:
cd \
mkdir %SRCDIR%
cd %SRCDIR%
set CVSROOT=:pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot
cvs co mozilla/client.mk
@pause

branchのソースを取得する場合、cvs co mozilla/client.mkを cvs co -r MOZILLA_1_8_BRANCH mozilla/client.mkのように、 -rに続けて、branchのタグ名を記述します。

次に以下のバッチファイルを作成して必要なソース、残り全てを取得します。 以下のproductの部分を修正するバグにあわせて、 Firefoxならbrowser、Thunderbirdならmail、Seamonkeyならsuiteと設定します。

次回以降のソースコードの取得はこのバッチファイルを実行するだけです。 (先のバッチファイルは別のフォルダに取得しなおす場合にのみ使います。)

set SRCDRV=c
set SRCDIR=\mozilla-src
set HOME=%SRCDRV%:%SRCDIR%
%SRCDRV%:
cd %SRCDIR%\mozilla
make -f client.mk checkout MOZ_CO_PROJECT=product
@pause

カンマ区切りで複数のプロダクトをビルドできるだけのソースコードを取得する場合、 productにカンマ区切りで名前を列挙します。例えば、browser,mailとします。

以下のようなメッセージが出たら、取得成功です。

checkout finish: Tue Apr 26 00:47:43 2005
make[1]: Leaving directory `/cygdrive/c/mozilla-src'

続行するには何かキーを押してください . . .

set SRCDRV=c
set SRCDIR=\mozilla-src
%SRCDRV%:
cd %SRCDIR%
set CVSROOT=:pserver:anonymous@cvs-mirror.mozilla.org:/l10n
cvs co -r MOZILLA_1_8_BRANCH l10n/ja
@pause

必要なソースコード全てが正常に取得できたら、今度はそれをビルドしてみます。 実際に修正する前に、実際にそのソースコードがビルドできるかテストしてみた方が良いでしょう。

もし、tinderboxを見て、 WINNT 5.2 gaius Dep releaseが赤色で表示され、燃えていたらおそらくビルドに失敗しますので、 対策のパッチがチェックインされるまで待ちましょう。 パッチがチェックインされたら、再び、上記のバッチを実行し、差分を取得してください。

. $topsrcdir/browser/config/mozconfig

# dist dir
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/firefox-normal-build

# Options for 'configure' (same as command-line options).
ac_add_options --disable-tests
ac_add_options --disable-logging
ac_add_options --enable-optimize

ac_add_options --enable-shared
ac_add_options --disable-static

#for debug
ac_add_options --disable-debug

# for Installer
ac_add_options --disable-installer

. $topsrcdir/browser/config/mozconfig

# dist dir
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/firefox-debug-build

# Options for 'configure' (same as command-line options).
ac_add_options --disable-tests
ac_add_options --disable-logging

ac_add_options --enable-shared
ac_add_options --disable-static

#for debug
ac_add_options --enable-debug

# for Installer
ac_add_options --disable-installer

. $topsrcdir/browser/config/mozconfig

# dist dir
#mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/firefox-normal-build

#for l10n
ac_add_options --enable-ui-locale=ja

# Options for 'configure' (same as command-line options).
ac_add_options --disable-tests
ac_add_options --disable-logging
ac_add_options --enable-optimize

ac_add_options --disable-shared
ac_add_options --enable-static

#for debug
ac_add_options --disable-debug

# for Installer
ac_add_options --enable-installer
ac_add_options --enable-single-profile
ac_add_options --disable-profilesharing

ac_add_options --enable-application=suite

# dist dir
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/seamonkey-normal-build

# Options for 'configure' (same as command-line options).
ac_add_options --disable-tests
ac_add_options --disable-logging
ac_add_options --enable-optimize

ac_add_options --enable-shared
ac_add_options --disable-static

#for debug
ac_add_options --disable-debug

# for Installer
ac_add_options --disable-xpinstall

set SRCDRV=c
set SRCDIR=\mozilla-src
set HOME=%SRCDRV%:%SRCDIR%
set MOZ_TOOLS=c:\moztools
set MOZCONFIG=c:\firefox.dev.mozconfig
set path=%PATH%;%MOZ_TOOLS%\bin
CALL "%VS_COMNTOOLS_FOR_MOZ%vsvars32.bat"
%SRCDRV%:
cd %SRCDIR%\mozilla
make -f client.mk build_all_depend > build.log
@pause

続行するには何かキーを押してください . . .

c:
cd \mozilla-src\mozilla\browser\installer
make installer
@pause

c:
cd \mozilla-src\mozilla\mail\installer
make installer
@pause

SET PATH=C:\Perl\bin\;%PATH%
c:
cd \mozilla-src\src\mozilla\xpinstall\wizard\windows\builder
perl build.pl
@pause

ビルドに成功したら、実際にソースコードを修正してみましょう。 ソースを修正した場合、取得したソースをテキストエディタで直接修正します。

ここで、利用するテキストエディタには制限があるので注意して下さい。 まず、UTF-8N(つまり、BOM無し)が扱えるものでなくてはいけません。 ほとんどの場合はASCII文字しか無いファイルの修正になると思いますが、 all.jsを修正する場合には必要です。

また、改行コードは全てLFで統一されていますので、LFを改行コードとして読み込み、 及び書き込み可能なテキストエディタでなくてはいません。

これらの条件を満たしたテキストエディタで修正を行ったら、 再びビルドして、修正を確認してください。

なお、修正にあたっては以下のことに注意してください。

• インデントは原則、スペース二文字(一部、例外あり)
• 水平タブ文字を使わない
• 空行は改行のみ、空白を入れない(自動インデント機能のあるエディタを使用する場合は要注意)
• クロスプラットフォームになるように記述する
• その他、ガイドラインに従う
• その修正箇所の周囲がガイドラインに従っていない場合、ガイドラインよりも周囲にあわせる
• 過度にコメントを書かない
• 他人のソースコードをコピーしない

特に、空白の使い方(比較演算子の周りには空白を入れる、引数はカンマの後に必ず空白を入れる等)は周りのソースコードに従い、 一人で、そのソースコードを書いたかのように修正することを心がけてください。 ただし、一行80文字までという制限は他が違反していても、レビュー時に駄目出しされることが多いので、 あらかじめ、きちんとしておきましょう。

会社勤めをしていた時によく目にしたのですが、ソースコードを見れば分かることをわざわざコメントに書く人がいます。 これはやめてください。コードから意味が分かりにくい場合はコメントを書くべきですが、 分かるコードにわざわざコメントを付けるのは余計なことです。 むしろ、ソースコードの見通しを悪くするので良くありません。

また、他人のソースコードは一切利用しないように注意してください。 ネット上で「自由にコピーしてかまいません」と書いてあってもそれは厳禁です。 オープンソースは厳密なライセンスの元で公開されているので、 そのライセンスに従って書かれたソース以外が混入されているとまずいのです。

修正内容を確認し、副作用(regression)が無いことを確認したら、パッチを該当のバグに投稿しましょう。

まずは、修正した差分をdiffを使って抽出します。 では実際に作業してみましょう。

コマンドプロンプトを開いて、c:\mozilla-src\mozillaに移動してください。 次に、以下のようにコマンドを叩きます。 今回、修正箇所がc:\mozilla-src\mozilla\layout\generic\nsTextFrame.cppと、 c:\mozilla-src\mozilla\layout\base\nsCSSColorUtils.cppの二つのファイルだと仮定します。

C:\mozilla-src\mozilla>cvs diff -u8p layout/generic layout/base

これを実行すると、ファイルの差分が表示されます。 この段階で、意図しない差分が出ていないか確認してください。 もし、関係無いところが差分として出ていたら、差分として出ないように、ソースを再度修正してください。 また、修正した場合は、(どんなに簡単な修正であっても)必ず、ビルドできるか確認してください。

差分が、意図したものとなったら、今度はこれをファイルに書き込みます。 以下のコマンドで、patch.txtに差分を書き込んでください。

C:\mozilla-src\mozilla>cvs diff -u8p layout/generic layout/base > patch.txt

cvs diffは必ず、mozilla/で実行してください。

続いて、このパッチを該当バグに投稿します。 該当のバグで以下のCreate a New Attachmentをクリックしてください。

この後のファイルの添付画面で、patch.txtを添付してください。 そして、Content Typeのpatchにチェックを入れてください。

DescriptionにはPatchと書いてください。 私は、Patch rv1.0という形式で、バージョン番号を付けています。 この方が、あとで複数のパッチを投稿した時に、コメントが付けやすくなりますので、お勧めです。

Commentには、そのパッチの修正内容には説明が必要だと思った場合はここに書き込んでください。

Flagsはレビューを申請するためのものです。 これについては、次のセクションを読んでください。

パッチを提出する場合、必ず先に自分をCCに追加しておきましょう。 パッチについて議論する際に、あなたに連絡メールが届かないのでは何の意味もありませんし、失礼です。

パッチを申請して、レビューが始まっても、あなたがそのバグの担当者(Assigned To)になっていない場合、 私にメールで連絡してください(連絡先)。 私が、あなたを担当者に変更します。 担当者になると、バグの編集権限を持たない人であっても、そのバグでは編集権限があることになります。 また、ステータス管理というマネージメントの面から考えても、あなたが担当者でいるべきですので、 忘れないようにしてください。

toolkitは独特のレビュー規則が存在します。 toolkitのレビューに関しては、以下を参考にしつつ、ルールそのものは、 オフィシャルのドキュメントを参照してください。

提出したパッチは担当者のレビューを受けなくてはいけません。 そのためには、パッチに合ったレビュアにレビューを申請しなくてはいけません。

パッチのレビューは、パッチの提出時と、提出後にActionsのEditから(以下のスクリーンショット参照)申請できます。

ここで、reviewで?を選択し、その横にレビュアのメールアドレス(bugzilla登録アドレス)を書き込みます。

自分のレビュアが誰なのかは、自分で調べなくてはいけません。 レビュアは一般的にそのモジュールのオーナです。 モジュールオーナの一覧はほぼ、Mozilla Module Ownersに書かれています。 ここで、担当者を調べて、メールアドレスを書き込んでください。 ただし、ここに書かれているメールアドレスと、現在のbugzillaのアカウントとは異なっている場合がありますので、注意してください。 最新のメールアドレスを探したい場合、レビューを頼む人が関わったバグをCVSのログから探してください。 そこに、その人のコメントがあれば現在のアカウントが分かります。

もし、複数のレビュアにレビューを申請しなくてはいけない場合ならどうすれば良いのでしょうか? 答えは、そのパッチをレビュア単位に分割して、再度、パッチを投稿し、パッチごとにレビューを申請することです。 実際にパッチをあててテストしようとする人がいた場合にはひとまとめになったパッチがあった方が良いので、 全てのパッチをひとまとめにしたパッチも常に提出しておいてください。 つまり、分割した各パッチを修正したら、必ず、全パッチをまとめたパッチも提出するようにしましょう。 複数のパッチを提出した例としてbug-org 276727を挙げておきます。

もし、モジュールオーナーが見つからない場合はどうすれば良いのでしょうか? toolkit以下を修正した場合等には、よくある話です。 この場合、LXRで、自分の修正したソースコードを見てください。 そして、ページ右上にある、CVS Logを見ます。 ここでは、Logの中に、r=または、r+sr=という形で、誰がレビューを行ったか、メモが残されています。 このメモから最近、どの人物が多くレビューを行ったか調べて、その人にレビューを申請しましょう。

もし、レビューを申請してから、一週間以上、返答が無かった場合はどうすれば良いでしょうか? レビュアの中には、フルタイムでMozillaのために働いているわけでは無い人もいます。 ですから、二、三日の間に必ずレビューが行われるとは限りませんので、一週間ぐらいは待ってください。 もし、一週間たっても反応がなかった場合は、レビュアに直接メールを出して、レビューをお願いしてください。 (失礼が無いように、注意してメールを書きましょう。) それでもレビューが行われない場合、他のレビュアに変更した方が良いでしょう。 各モジュールのPeersにレビューを申請してみてください。(もし、その人が適任ではなかった場合、その旨、連絡があるでしょう。)

早ければその日の内にレビューが行われます。 レビューを行った結果、何らかの解答があります。 もし、レビューが通れば、review grantedというsubjectのメールが届き、Flagsがreview+となります。 レビューが通った場合は次のスーパーレビューと承認に進んでください。

しかし、多くの場合はレビューにより、駄目出しが行われます。 丁寧なレビュアはここで、Flagsをreview-として、その理由をコメントしてくれます。 ですが、多くの場合はFlagsを変更せずに、修正点だけ列挙されることがあります。 どちらにしても、コメントに基づいて、再びパッチを作り直してください。 そして、パッチができたら、再度、パッチを投稿し、レビューを申請してください。 再投稿時にはあわせて、古いパッチをobsoleteとすることを忘れないでください。

ここで、注意しておきたいのは、Flagsを変更してくれなかった場合です。 この場合、次のレビューを申請する前に、自分でreview-に変更しておきましょう。 もし、新しいレビューを申請した後で、この変更を行うと、 レビュアは新しいパッチを自分でreview-にした、つまり、 次のパッチの作成に入ったと勘違いするかもしれないからです。

レビューが通ったら、今度はスーパーレビューを受けます。 一部、スーパーレビューを受けなくても良いモジュールもありますが、大抵のモジュールはスーパーレビューを必要とします。 詳しくは「どのコードが super-review を必要とするのでしょう？」を参照してください。

スーパーレビューはレビューの申請と同様にActionsのEditにある、以下のフォームから申請できます。 superreviewの項目を?とし、スーパーレビュアのメールアドレスを入力します。

レビュアがreview+とする時に、コメントにここを修正するという条件で……という条件を付けている場合があります。 この場合、先に該当箇所を修正したパッチを投稿しなおして、新しいパッチでsuperreviewを申請しましょう。 新しいパッチを投稿する際は、自分でreviewの項目を+にしておいてください。

スーパーレビュアに誰を指名するかは難しい問題です。 基本的には「Mozilla コードのレビュー」の一覧表から適切な人を選んで、 その人にリクエストすることになります。 しかし、スーパーレビュアはレビュアに比べて、人数が圧倒的に少ない上、多忙な人が多くて、全く相手にされないこともあります。 その場合、やはりCVSログからそのモジュールのスーパーレビューをよく行っている人に申請しなおした方が良いでしょう。 スーパーレビュアはレビュアほど、モジュールの棲み分けがなされていないことも覚えておくと良いでしょう。

もし、スーパーレビュアがレビュアと同じ場合、レビューの申請時に、 同時にスーパーレビューも求めます。 そうしないと、レビュアに余計な手間をかけてしまうので、間違えないようにしましょう。

スーパーレビュアからsuperreview+をもらうことができれば、ほとんどの場合、 次のチェックインに進むことができます。

しかし、driversがツリーを管理している期間は更にdriversの承認(approval)がなければチェックインすることができません。 この期間とは、アルファリリースやベータリリースの直前や、ベータリリースからファイナルリリースまでの間のことです。 今が、その期間なのかどうかは、 Seamonkeyのtinderbox に告知があるかどうかで判断できます。

もしくは単純に、レビューの申請フォーム上に、approval1.8b2といった申請フォームがある場合は申請が必要と言えます(例えば以下のスクリーンショットのような場合)。 この判断方法の場合、TrunkへのapprovalかBranchへのapprovalであるかを判断しなくてはいけないことに注意してください。

承認申請はこのように、レビュー等と同じ申請フォームから行います。 ここで、?を選択し、送信するだけです。 承認の審査者を指名する必要はありません。

申請の際には、コメント欄に(簡単にで良いので)、そのパッチによる副作用(regression)のリスク(low もしくは high)、 その修正がどうして、次のリリースにおいて修正されているべきなのかを書き込んでおいてください。

review+、superreview+、そして必要ならapproval+も得られたら、 そのパッチはいよいよ、Trunkへのチェックインの時を迎えます。 しかし、これを読んでいるあなたはおそらくチェックイン権限を持たないはずです。 そのため、チェックイン権限を持つ人に、チェックインを依頼しなくてはいけません。

チェックインを依頼する前に、まずは以下のことを確認してください。

そのパッチは、最新のソースコードに適用できるのか?

パッチファイルは、そのパッチファイルに含まれている行が、他のバグ修正により修正されている場合、 パッチを適用できなくなっています。このテスト手順は以下のようになります。

1. 開発用とは違うフォルダにソースコードを取得しなおす(\mozilla-citestにダウンロードしたと仮定)
2. \mozilla-citest\mozillaに最新のパッチをpatch.txtという名前でコピーする
3. コマンドプロンプトを開き、\mozilla-citest\mozillaに移動する
4. patch -p0 < patch.txtを実行する

もし適用できない場合、最新のソースを使って、再びパッチを作り直すという作業が必要になります。 この際に、ロジックが大きくなるようなら、再びレビューから受け直さなくてはいけません。 また、自分の修正をチェックインすることで、同じ場所を修正したバグが再発しないかどうかの確認も必要です。

そのパッチを最新のソースコードに適用した状態でビルドできるのか?

パッチファイルから、元々ある変数や関数(特に、他のファイルの関数)を利用している場合、 それらが別のバグ修正により、名称変更等されている場合があります。 ですから、最新のソースコードにパッチを適用し、ビルドできるかどうかを確認する必要があります。

チェックイン後にビルドに失敗することがあると、 その理由によってはあなたの信用は大きく傷つきますので注意してください。

これらの問題がもしあった場合、新たにパッチを作り直して投稿してください。 もし、その修正によってロジックが変更された場合は、新たにレビューからやりなおしてください。

全ての問題が無いことが確認されたらいよいよチェックインを依頼しましょう。 依頼は、そのバグに名指しで書き込むもよし、直接メールを出すもよし、これは個人の自由です。

依頼相手は、通常はそのバグのレビュアでかまいません。 しかし、断られることもあるので注意してください。

また、チェックイン依頼は、私にしてもらってもかまいません。 通常の態勢であれば一日以内にチェックインさせてもらいますし、やりとりも日本語でできます。 直接、メールで私に連絡してください。

チェックインが完了すれば、いよいよ(Trunkでの)バグ修正完了です。

もし、Branchでも修正が必要なのであれば、再度、Branchのソースコードを元に作業しなおさなくてはいけません。 その場合、ロジックが同じなら、Branch用のパッチを投稿し、自分でreview+、 superreview+とし、approvalだけ申請してください。

最後に、全ての作業が終了したら、バグのResolutionをfixedとして終了です(多くの場合、チェックインした人がこの変更を行います)。 お疲れ様でした。