Gaia のパッチを提出する

Gaia にパッチを送るのは、慣れるまでややトリッキーでしょう、なぜなら Bugzilla と Github と、正しいシーケンスとするために特殊なフラグを使用することが含まれているためです。

Autolanderを使った容易なパッチ提出

Autolander はGaia (と、一緒に使用されるその他のプロジェクト) にパッチを送るのに要する、多くのステップを自動的に扱うツールであり、その過程の時間短縮とエラー削減になります。Autolander は、プルリクエストとバグを自動で添付したりして、Bugzilla から Github へのワークフローを統合します。Autolander を使用するには:

1. 最初に、bugzilla にバグを登録して、まだ誰もコード変更していない場合に、何を行なっているのかを示します。これは Firefox OS product の下に投稿すべきで、かつあなたのコードが何をするのかについて良い説明を付けます。
2. 今度はパッチの プルリクエストを作成する 時間です。最初から我々のガイドに従ってきている場合、Gaiaリポジトリをローカルにフォークして一意に名づけたブランチに対して変更を加えているはずです。次に変更を 「git add .」 して、「git commit -m 'コミットメッセージ'」とします。
3. 'コミットメッセージ'にはBugzilla のバグ番号とバグのタイトルを含める必要があります。それに加え、パッチが何を行うのか、誰がコミットしたのかを記述します。例えばこう:

   Bug 9999999 - Fix that annoying bug R=johndoe

4. github上の、あなたのGaiaフォークにコードをプッシュして、次にコードを含めてもらうためにPR(プルリクエスト)を作成します。
5. プルリクエストが開かれたら、PR のタイトル内に見つかるバグに対して、自動的に添付されます。
6. 将来的には、添付ファイルが推奨レビューワーから r+ を与えられた時、キーワード項目に autoland キーワードを追加して、Gaia master にコードをランドできるようになります(つまりAutolander はコードをランドするでしょう: PR をマージして、バグに対してコミットを置き、バグが解決済みだとマークするまで) しかしながら、現在ここの部分はまだ作業中なので、いまのところは checkin-needed キーワードを追加して、他の適切な人があなたの代わりにランドしてくれるのを待たねばなりません。

手動でのパッチ提出

何らかの理由で、Autolander に頼りたくない場合、下記の手順に従って、手動でGaiaにパッチを提出します。

1. 最初に、bugzilla にバグを登録して、まだ誰もコード変更していない場合に、何を行なっているのかを示します。これは Firefox OS product の下に投稿すべきで、かつあなたのコードが何をするのかについて良い説明を付けます。
2. 今度はパッチの プルリクエストを作成する 時間です。最初から我々のガイドに従ってきている場合、Gaiaリポジトリをローカルにフォークして一意に名づけたブランチに対して変更を加えているはずです。次に変更を 「git add .」 して、「git commit -m 'コミットメッセージ'」とします。
3. 'コミットメッセージ'にはBugzilla のバグ番号とバグのタイトルを含める必要があります。それに加え、パッチが何を行うのか、誰がコミットしたのかを記述します。例えばこう:

   Bug 9999999 - Fix that annoying bug R=johndoe

4. github上の、あなたのGaiaフォークにコードをプッシュして、次にコードを含めてもらうためにPR(プルリクエスト)を作成します。
5. PR の URL を bugzilla のバグに添付します (Add an attachment のリンクに従い、ファイル入力モードにて添付としてペーストするテキストを選び、PR の URL を添付の内容として入力し、簡単な説明を入力します)。
6. Bugzilla バグへの PR の添付上に、レビューを依頼します。review: ? フラグを添付物に加えて依頼できるでしょう。次に、あなたのコードが適用されるモジュールのオーナーを入れます(詳細は モジュールオーナーのページ を見て下さい。)
7. パッチをレビューするレビューアが割り当てられるのを待ちます。この時点で、多分レビューアは Github の PR に 変更/修正 を要求するようコメントして、Bugzilla にリンクするでしょう。
8. レビューアのコメントに対応して、前と同様に PR に更なる変更をプッシュして、 review: ? フラグを外します。
9. いったんレビューアのコメントが向けられて r+ フラグ (レビュー/承認済みを意味します) が付けられると、全コミットを1つにつぶし(squash)ます (下記の Tips_on_Gaia_Rebasing の節も読んで下さい。)。
10. キーワード項目に checkin-needed キーワードを加えます。この時点で誰かがあなたのパッチを Gaia のソースに定着させる (PR をマージするなど) のを待つ必要があります。
11. おめでとうございます! あなたのコードは Firefox OS の一部になりました!

GaiaのRebaseについてのTips

Gaia の master ブランチは常に(1日に何度も何度も)変更されています。2時間かかるパッチ作成をした後、master ブランチがあなたの下で変わっている事に気づくかもしれません。

あなたの作業ブランチ (例. my-code-fix) から、最初に rebase を試すのはこのようになります:

git checkout -b my-code-fix-r1
git pull --rebase upstream master

衝突がなければ、このように続けます:

git checkout my-code-fix
git pull --rebase upstream master
git branch -D my-code-fix-r1

衝突のある場合、衝突した変更の開発者と一緒に解決して、上記の rebase プロセスを繰り返します。

エンジニアリングバグに対してステータスを トラッキングする

Mozillaは Sheriff(保安官) という特別権限を持っています。 Sheriff にはコードをマージしたり、ブランチ状態をメンテする責任があります。Firefox OS チーム内にいるテストの失敗を調査するsheriffの数は限られているため、sheriff が不完全なパッチの全てを元に戻すのは困難です。

Firefox OS では、ゆえに、パッチが動作するか否かの検証で失敗した場合、問題を解決する新しいパッチを定着させるための新しいバグを開くのが好まれます。これはQAとプロマネのチームにトラッキングステータスの問題を引き起こします。

ゆえに、我々はステータストラッキングバグとエンジニアリングバグを分けています。

• ステータストラッキングバグは "meta" キーワードで識別されます。ステータスバグは受容可能な条件を満たさない場合や、再現手順に失敗する場合にも、再度開かれる事があります。
• エンジニアリングバグは自動テストに失敗したり、全く動作しない時だけに開かれるべきです。あるパッチでエンジニアリングバグの一部分が修正された場合、バグを複製して "see also" 項目にオリジナルのバグへの参照を記し、失敗するポイントを記述します。

たまたまステータストラッキング中のバグを定着させた場合に回復する

こうなった場合、パニックにならないで下さい。たまたまパッチを定着させたり、レビューを得たり、トランクに定着させたり、何も修正されていないと報告されたりした場合、なすべきことはここにあります:

1. Bugzilla の UI の右下隅の "Clone this bug" を押して新規バグを作成し、オリジナルの項目の大半をそこにコピーします。ホワイトボード、キーワード、STR/ユーザのストーリーが新しいバグにコピーされているのを確認します。
2. 新規のバグが古いバグにブロックされるようセットします。新規バグは、新しいステータストラッキングバグになるでしょう。
3. needinfo フラグを使って、適切なプロマネステータストラッキングバグが変更されたのが知れ渡るように警告します。Wiki上にて Firefox OSの別のプロマネのメールアドレスを発見 できます。
4. 新規のエンジニアリングバグを作成して、故障手順や受容可能な条件を記述します。また、この新規バグを使ってステータストラッキングバグをブロックします。
5. 新規バグの解決法を提供するよう試みます。楽しくハックしましょう!!!

パッチを別のブランチに取り込むには

バグの別バージョンのタグが見られる事もあるでしょう。Firefox OSの古めのブランチにパッチを持ち上げたい場合、パッチを定着させる規約を満たすかどうか確認します。詳細はB2G Landing pageで見つかります。