これは Firefox Developer Tools に貢献するためのガイドです。高レベルでは、コントリビュータのワークフローは次のようになります。

  • Get set up
    • Firefox のソースコードを入手しましょう
    • Firefox をビルドできるようにビルド環境を手に入れましょう
  • Fix a bug
    • 修正するバグを見つけましょう
    • それを修正し、いくつかのテストを書きましょう
    • あなたの修正はレビューされます
  • Check in your fix
    • チェックイン可能なパッチを作成する
    • 統合テストを実行する
    • リリースエンジニアにパッチをチェックインするよう依頼する

このガイドでは:

  • 次のように仮定します
    • あなたは Git を知っているが Mercurial は知っていないし、今は Mercurial を学ぶことに興味がない
    • あなたは1つ以上の貢献をすることに潜在的に興味がありますので、統合テストを実行するためのセットアップに少し時間を費やしても構いません
  • DevTools コード自体の設計と実装はカバーしていません。このためには、#devtools IRC チャンネルや作業中のバグで助けを求めるのがよいでしょう
  • 可能なワークフローは1つだけです。このワークフローのさまざまな部分でさまざまなテクニックが使用されています。ここで説明するワークフローは最も効率的ではないかもしれませんが、比較的簡単で安定したワークフローです。追加のワークフローについては、このドキュメントの「代替技術」のセクションを参照してください

Mozilla のソース管理:Mercurial と Git

Mozilla のソースコードを扱う際の複雑さの中には、Mozilla が Git ではなく Mercurial をバージョンコントロールシステムとして使用していることに由来するものがあります。Mercurial について知っていればこれは問題ありませんが、Mozilla に来るほとんどの人は Git に精通していますが、Mercurial には慣れていません。さらに、ほとんどの人は、Firefox にいくつかの貢献をするために新しいバージョン管理システムを学ぶことに興味はありません。

https://github.com/mozilla/gecko-dev にある Firefox ソースコードの Git ミラーがあります。それは最新の状態に保たれており、それを使って Firefox をビルドし、あなたの貢献について作業して、最終的なパッチの承認を得ることができます。しかし、Git ミラーは読み取り専用です。Git だけを使って Firefox に変更を戻すことはできません。Firefox の変更は、Mercurial リポジトリにコミットする必要があります。

通常、最初のパッチでは、あなたのメンターがあなたのためにパッチをコミットし、Mercurial についてはまったく心配する必要はありません。しかし、定期的な貢献者になりたい場合は、統合テストを実行する必要があります (これは Mozilla の専門用語で試してみることです)。これを行うには Mercurial リポジトリにプッシュできる必要があります。

このガイドでは、Git をあなたの開発に使用しながらこれを行うことを可能にする設定について説明しますが、他の設定もあります。

セットアップを開始する

Firefox のソースを取得する

https://github.com/mozilla/gecko-dev から GitHub ミラーをクローンします。これには時間がかかることがあります。

git clone git@github.com:mozilla/gecko-dev.git

DevTools チームは開発のために inbound ブランチを使用しますので、ブランチをチェックしてください:

cd gecko-dev
git checkout inbound

ビルドの前提条件

ソースコードには mach というツールが含まれており、これを使って Firefox のビルド、実行、テストを行います。また、ビルド環境を設定する bootstrap コマンドもありますので、今すぐ実行してください:

./mach bootstrap

これはすべての前提条件をインストールするので、しばらく時間がかかることもあります。

Mercurial のセットアップ

次に、Mercurial Firefox リポジトリを並列ディレクトリにクローンします。

cd ..
hg clone http://hg.mozilla.org/integration/fx-team

(mach bootstrap にはすでに Mercurial がインストールされているはずです。)

次に、別のパラレルディレクトリに Mozilla git ツールをインストールします。

git clone https://github.com/mozilla/moz-git-tools

このディレクトリを .bash_profile$PATH に追加することで、このリポジトリ内のスクリプトがシェルによって実行可能であることを確認してください。

この時点で、次のようなディレクトリ構造が必要です。

dev
   /fx-team
   /gecko-dev
   /moz-git-tools

Firefox のビルド

Firefox をビルドするには gecko-dev ディレクトリに移動し、./mach build を実行します。これにはしばらく時間がかかるでしょう:

cd gecko-dev
./mach build

すべてを構築したら、DevTools だけをビルドすることができます:

./mach build devtools/*

これははるかに高速です。

fx-team からローカルリポジトリに最新の変更をプルするたびに、 "clobber" する必要があることに注意してください。"clobber" は  "make clean" と似ています。 インクリメンタルビルドを実行しようとした後にクローバービルドを行うように指示する大きなエラーメッセージが表示されたときに、クラウドする必要があることがわかります。クローバービルドを実行するには、次のコマンドを入力します。

./mach clobber
./mach build

Firefox の実行

ビルドした Firefox を実行するには:

./mach run

もしくは

./mach run -P my-profile

これは mach に "my-profile" という名前のプロファイルを実行するように指示します (あなたが望む任意のプロファイルに名前を付けることができます)。プロファイルには、閲覧履歴、調整済みの設定、アドオン、ブックマークなど、基本的な Firefox インストールのすべてのカスタマイズが保存されます。指定したプロファイルがまだ存在しない場合は作成されます。

テストの実行

テストを実行するには、mach test を使用して、単一のテストファイルまたはテストファイルを含むディレクトリを渡します。

./mach test path/to/test

バグの修正

バグトラッキングには Bugzilla を使用していますので、サインアップする必要があります。

バグを見つける

あなたが何をしたいのかが分かっていない場合は、firefox-dev.tools サイトで良い最初のバグやメンタリングされたバグのリストをチェックしてください (あるいは、Bugzilla でこれらのリストを見つけることもできます: good-first, mentored)。この開いている開発ツールのバグの一覧には、興味深い他の項目があります。

質問する

バグに取り組んでいる間は、助けを求めることができます。連絡先を知らない場合は、このページが役立ちます。メンターがまだ割り当てられていないバグでもメンターになることを躊躇しないでください。

あなたのバグにコメントを追加して誰かからの回答が必要な場合は、コメントボックスの下にある "Needs more information" (一般にNIと略して) チェックボックスをオンにし、電子メールアドレスを追加することができます:

これにより、バグが注目されるようになります。

フィードバックを求める

適切なレビューの準備ができていないが、問題を解決するための考え方をフィードバックしたい場合は、作業中のパッチを添付してフィードバックを求めることができます。

パッチを添付するには、「添付ファイルを追加する」というラベルのバグのリンクをクリックします。これにより、パッチを添付したり、フィードバックを求めたり、レビューを依頼することができる新しいページが開きます。

レビューを求める

レビューの準備ができたら、パッチを作成してください。この時点でパッチは、fx-team ブランチにきれいに適用される限り特別な書式設定は必要ありません。たとえば、単に git diff fx-team の出力を使用することができます。あなたが適切なレビューワーを見つけるのが難しい場合は、このページを参照することができます。

ただし、fx-team ブランチには完全に適用する必要があるため、パッチを作成する前に作業ブランチを再配置し、競合を修正してください。

テストを含まずにレビューを求めることができます。しかし、あなたがあなたの貢献をチェックインできるようになる前に、あなたはテストを書く必要があります。

レビューコメントを扱う

レビュー担当者が修正が必要なものを見つけたら、バグでそれらを書き留めてレビューに拒否 (r-) をマークします。このことについて落胆してはいけません。経験豊富な Firefox 開発者であっても、パッチを拒否されるのはとてもよくあることです。

コメントに対処する新しいパッチを作成して添付し、再度レビューを依頼してください。パッチを添付するときは、この新しいパッチが古いパッチを廃止していることを示すボックスをチェックします。

あなたのパッチが承認されると、査読者はそれを r+ とマークします。

レビ担当者には「ニット」と呼ばれるコメントが追加される可能性があります。修正するべきですが、別のレビューは必要ありません。

あなたがパッチで r+ を持っていても、ニットを修正したり、パッチを再生成しなければならない場合は、" r+ を引き継ぐ" ことができます。これはあなたが新しいパッチを添付するときに、あなた自身を "r+" とマークすることができるということです。

チェックイン

今ではテストを書いた機能を実装しましたが、すべてレビューされています。最後のステップでは、統合テストを実行し、合格した場合はチェックインを依頼します。

チェックインするパッチを作成する

リベース

まず次のような形式のコミットメッセージを使用して、変更を1回のコミットにリベースする必要があります。

git commit -m "Bug 12345 - Summary of bug. r=<name of reviewer>" .

名前とメールの設定

.gitconfig であなたの名前と電子メールアドレスが正しく設定されていることを確認してください。

[user]
    name = My Name
    email = me@my-domain.com

hgp のセットアップと実行

gecko-dev クローンの .git/config ファイルに次の行を追加します。

[alias]
hgp = "show --binary --find-renames --format=\"# HG changeset patch%n# User %an <%ae>%n%B\" -U8"

これは githgp というコマンドを追加します。これは最後にコミットして Mercurial スタイルのパッチに変換します。

次のように実行します。

git hgp HEAD > Bug12345.patch

これにより、Mercurial 形式のパッチが生成されます。このパッチをバグに添付してください。

試しにプッシュする

Mozilla は「試用サーバー」と呼ばれるサーバーを使用して統合テストを実行します。試用サーバーを使用するには、パッチを適用し、特別にフォーマットされたコミットメッセージを追加します。このメッセージは、サーバーにテストするプラットフォームを通知し、それを特定の Mercurial リポジトリにプッシュします。次に、試運転サーバーは、コミットメッセージの指示に従って統合テストを実行すると、結果をオンラインで見ることができます。

まず、試用サーバーにプッシュするにはアクセスレベル1をコミットする必要があります。コミットアクセスレベル1を要求するバグを報告し、使用する SSH 公開鍵を添付します (あなたが好きな場合はGitHubと同じものを使用できます)。そして、あなたのメンターにあなたに保証を依頼してください。

次に、Mercurial リポジトリ (Getting setup の fx-team) が最新のものであることを確認します。あなたの Git リポジトリ (Getting setup の gecko-dev) があなたのパッチを加えて、それと同期していることを確認してください。

次に、gecko-dev ディレクトリに移動して、次のようなコマンドを試してみてください:

git push-to-try ../fx-team -b do -p linux,linux64,macosx64,win32 -u xpcshell,mochitests -t none

長い文字列のパラメータは、使用するプラットフォームと実行するテストをサーバーに指示します。上記で引用したセットは DevTools の変更点の共通セットですが、必要に応じてメンターが別のセットを選択するのを手助けすることができます。

これが成功すると、コマンドの出力から、ビルド/テストの実行の進捗状況を確認するための URL が表示されます。

試行結果の解釈/再試行

完全な試しビルド/テストの実行には数時間かかります。結果を示すページは次のようになります。

各行はプラットフォームを表し、行の各リンクされた項目はテストスイートを表します (たとえば、dt1dt2dt3 は DevTools テストスイートです)。理想的には、これらのすべてが緑色であることを望みます。赤はビルドエラー、オレンジはテストの失敗、紫はインフラストラクチャの障害です

多くの場合、テストの失敗があり、これらはオレンジ色で表示されます。リンクされた項目をクリックすると、下部のペインでテストの失敗に関する詳細な表示が表示されます。

テストの失敗は、Bugzilla の既知の断続的なバグに関連していることがよくあります。その場合は詳細が表示されます。上記のスクリーンショットは、このテストの失敗がバグ 1177730 に関連していることを示しています。

テストやビルドに失敗した場合、そのパッチが原因かどうかを判断する必要があります。あなたが行った変更と無関係で、断続的に知られているように見える場合、あなたのパッチによって引き起こされていない可能性があります。これを判断するのを助ける1つの方法はその仕事だけを再トリガーすることです。あなたは "リロード" アイコンをクリックすることでこれを行うことができます。

あなたのメンターとテストの失敗を話し合い、チェックインを依頼するかどうか、またはパッチに問題があるかどうかを判断してください。

checkin-needed キーワードの設定

チェックインを続行することを決めた場合は、try runへのリンクを含むバグにコメントを追加してください。パッチが原因ではないと思われるテストの失敗がある場合は、その理由を説明してください。次に、"checkin-needed" キーワードをバグに追加します。これを行うには、バグの「キーワード」テキストボックスをクリックし、「checkin-needed」と入力して Enter を押します。

数時間以内に、リリースエンジニアがパッチをツリーにチェックインします。

次は何ですか?

パッチがチェックインされると、ビルドとテストのもう1つのラウンドが行われます。それが成功すると、パッチは Firefox コードの mozilla-central ブランチにマージされます。その後、次の日に Firefox の夜間ビルドにパッチが表示され、Developer Edition の次のリリースに表示されます。

ヘルプの利用

ヘルプを得るための2つの最良の方法は次のとおりです。

  • バグで質問する
  • IRC の #devtools チャンネルで質問する。以前から IRC を使用したことがない場合は、このガイドの Mozilla で IRC を使用する方法を参照してください。

代替技術

上記のワークフローは Firefox Devtools 開発の唯一のワークフローではありません。多くのステップには代替技術があり、多くの場合、より効率的で高度なものですが、より実験的です。基本的なワークフローをカスタマイズするには、その一部をこれらの手法の一部に置き換えます。

  • Nightly でコントリビュート: Firefox のビルドやビルド環境の設定をしなくても、devtools のコードを変更して再読み込みできる新しい手法について説明しています。
  • git-cinnabar: このツールは Git と Mercurial の間のブリッジを提供し、Mercurial リポジトリをクローンする必要なしに変更を Mercurial にプッシュできます。

ドキュメントのタグと貢献者

このページの貢献者: silverskyvicto, wbamberg
最終更新者: silverskyvicto,