パッチを提出し、レビューを受け、Mozilla ソースツリーにコミットして貢献するための幾つかのステップです。この記事ではそのやり方を説明します。
パッチの提出プロセスは以下の図に書いてある通りです。そして、各ステップの詳細は次のセクションで説明します。
準備
全てのコードの変更は bugzilla.mozilla.org のバグによってトラッキングされています。バグがないものについてはコードレビューされず、レビューされないコードは受け付けません。重複を避けるために変更しようとしている内容が既に存在していないか、バグの検索をし存在しなければファイル(登録)してください。変更についてのほとんどの議論はバグ上で行います。そのため、バグには問題を正しく記載することが解決の鍵です。
バグが正しいプロダクト・コンポーネントとして登録されているか確認してください。もっと情報が欲しい時は、IRC チャンネルの #developers か、ニュースグループに問い合わせてください。
バグを作業している人は bugzilla 内のバグの "assignee" として登録されます。もし誰かがバグにアサインされていれば、その人に変更を調整するためにメールしてください。もしいなければ、バグの状態をあなたが作業していることがわかるようにステータスを変更し、バグの編集権限がある人に自分がアサインでいるよう依頼してください。
パッチが長いこと作られず他のコントリビュータが手をつけないことを避けるため、幾つかのチームでは、アサインされる前にパッチを添付する新しいコントリビュータを待っています。バグのコメントに興味を持つようなことを書くと、チームの誰かが普段使っているプロセスを教えてくれるかもしれません。
モジュールオーナーシップ
全てのコードはモジュールオーナーによって管理されています。モジュールオーナーはレビューをして変更を許可する役割を持っています。コードを書く前に、モジュールオーナーを確認し、変更提案を許可するか書くにしてください。彼らは新しいユーザーインターフェイス(UI review)、関数(API review)、または変更のテストケースを作成する人を探しています。
もしモジュールオーナーがわからない場合、IRC または ニューズグループに確認した方が良いです。変更するファイル履歴も活用できます。例えば、browser/base/content/browser.js の変更ログを MXR の "Hg Log" リンクをクリックまたは、 hg log browser/base/content/browser.js を実行することで確認します。"r=nickname" のようなログがチェックインメッセージに含まれていてそこからレビューアが誰かを質問することができます。
パッチを作成する
Mozilla ソースコードの変更はパッチで表現されます。パッチはバージョンコントロールにコミットするための基本です。
各パッチは１つの完全な変更を表現し、分割された変更だったらパッチも複数に分割します。もし変更が大きい場合、パッチは複雑になります。その時は、パッチを分割し、小さく簡単に読みやすいパッチに変更するためのステップを参考にしてください。これは変更のレビューを簡単にし、早いレビューを導き、公式なレビューの良い方法です。
Note: 適切なフォーマットでレビューを簡素化させるためのパッチを作るための情報については、patch の精製方法を参照してください。我々のレビューアチェックリストも参照して良いパッチの作成情報を見てください。
テスト
すべての変更をテストします。多くの場合、他の変更時にテストできるように自動テストが要求されます。自動テストができない場合、Limus tests と呼ばれる手動テストを使ってください。
変更がレグレッションを起こさないようにローカルで自動テストをするか、Mozilla の try server を使ってください。try server の権限がない場合でも、モジュールオーナーまたは開発者が IRC でジョブを動かすための手助けをしてくれます。
パッチを提出する
もしコントリビュータなら、パッチ提出に MozReview を使うべきです。使い方は MozReview User Guide を見てください。
もし Mercurial を使う場合、Bugzilla にパッチを添付する仕組みである bzexport extension をインストールします。bzexport の簡単なインストール方法は mach mercurial-setup を実行することです。その後、ターミナルから画面を切り替えることなく、Bugzilla にパッチをアップロードするために hg bzexport -e を実行します。
もし、MozReview や bzexport を使わない場合、bugzilla の Add an attachment リンクを使ってバグにパッチを添付します。レビューアや bugzilla ユーザーがパッチを読めるように patch チェックボックスにチェックを入れてください。
一部のパッチのアプローチ手段を確認したり、フィードバックを問い合わせすることを恐れないでください。コードと一緒に質問をされた時にコメントしたり提案することはとても簡単なことです。
レビューを受ける
コードレビューを通すことは Mozilla の品質管理の一つです。すべてのパッチはモジュールオーナーまたは、支持したピアによってレビューされます。モジュールを跨いだり、API を変更したり、セキュリティ関係の変更をする場合、レビューに加え、super-review も必須です。
レビュープロセスについての詳しい情報は、code review FAQ をご覧ください。もし変更がユーザーインターフェイスに影響を与える場合、フィードバッグやデスクトップ版 Firefox のフロントエンド変更のためによる ui-review を要求してください。
レビューやスーパーレビューを要求するには、bugzilla の添付ファイルリンクの詳細(Details)をクリックします。左側にラベルと共にドロップダウンが存在します。"review" を見つけ、フラグを"?"に変更し、モジュールオーナーかパッチをレビューしてくれるピアのメールアドレスを入力します。最後に送信することを忘れないでください！
注意: もしレビューアが１週間ほど応答しない場合は以下の方法をとってください:
- Moizlla の IRC サーバーの #developers に参加し、誰かレビューが遅れている理由を知っているか聞いてください。(その時に一緒にバグのリンクを添えてください）
- もしレビューがされていなければ、直接レビューアにメールをして、いつレビューができるか、または誰か他にレビューができないか聞いてください。
- 最後の手段としてnews.mozilla.org のニュースグループに問い合わせてみてください。
レビューコメントを修正する
最初っからパッチがパーフェクトな事はありません。レビューアは "review-" をつけ、そしてパッチを許可する前に修正すべき問題点を教えてくれます。要求しているリビジョンは参加を阻害する意図ではなく、変更の完成度を可能な限り良いものにするために奨励しているということを忘れないでください。レビューアの助言を注意深く修正し、新しいパッチを添付して再度レビューを出してください。
時々レビューアは"review+" と共に、スペルミスやインデントミスなどの修正すべき小さな変更を指摘する場合があります。全ての指摘を修正するべきですが、再レビューは不要です。変更を作成し、リビジョンを改訂したのちに、添付ファイルページに表示されている元のパッチの obsolete チェックボックスにチェックを入れてください。もしそのリビジョンに不安がある場合は、レビューを要求してください。
時々レビューした後で、コミット前の場合、誰かが衝突する変更を加えることがあります。もしマージがシンプルで影響を与えないような場合、アップデートしたバージョンのパッチを投稿します。それ以外はレビューが必要です。
もしレビュープロセスが２週間以上止まっている場合は、上述している "注意" を参考にしてください。
多くのオープンソースプロジェクトで、開発者は完全な状態でもパッチを許可し、それを完了し適用ます。Mozilla の文化では、レビューアはレビューだけして、パッチにコメントします。もし パッチ提出者が作成したリビジョンを諦めた場合、誰かがバグを引き取るまではパッチは存在し続けます。
パッチをコミットする
レビューが完了したらパッチはコミットできます。
パッチが適用されたアプリケーションをビルドしてください。それが動作させて自動テスト(そして完了したバグの動作)を確認し、 try server にプッシュしてください。(この時もコメントにバグを明記します)
テストしないパッチを提出するとコミッターの時間を浪費し、ツリーを炎上させます。全ての必要な確認を完了することで、全員の時間と努力を節約してください。
コミッターがパッチをチェックしやすいように、パッチを適切なフォーマットで作成してください。
バグに checkin-needed キーワードをつけます。(またはバグの変更権限がない場合は、誰かに追加してもらえるよう訪ねてください) コミット権限を持ったコミュニティーメンバーは通常１日程度で checkin-needed キーワードを持ったバグを見つけ、コミットします。もしパッチが時間帯によってチェックインされていない場合は、irc.mozilla.org の #developers に参加し、あなたの代わりにチェックインできる人を聞いてください。ほとんどの場合、ランド後に新しい問題をパッチが引き起こさないことを確認するために Try の実行結果のリンクが必要です。
もし自身でコミットできる場合は、Committing Rules and Responsibilities に従うことを忘れないでください。
レグレッション
自身の変更により、機能またはパフォーマンスのレグレッションが発生した状態です。特にパフォーマンスレグレッションの厳しいポリシーがあります。これは変更したコードがよくバックアウトされてしまうことがあり、修正して再提出する必要があるということです。レグレッションはテスト(自身がチェックイン前に行ったもの、また実施していないもの)が包括的に不十分ということを意味し、パッチを再提出するか、適切なテストを伴うレグレッションの修正をする必要があります。
いくつかパッチを作成したら、Mozilla source code のコミット権を取得することも考えてみてください。