ククログククログMozReviewでのFirefoxへのパッチ投稿方法(2019年4月12日追記)この記事で解説しているMozReviewは既に廃止されており、代わりにPhabricatorというツールを使うようになっています。この記事自体は歴史的文書として残していますが、パッチを新たに投稿したいという場合にはPhabricatorの解説を参照して下さい。はじめに前回の記事ではFirefoxへのフィードバックの仕方を紹介しました。この記事で紹介したように、Firefoxへのパッチ投稿は、以前はBugzillaにパッチファイルを手動で添付する形で行われていました。Boardベースのコードレビューシステムも導入されています。GitHubと同様にソースコードにインラインでコメントを付けられますし、パッチをリモートリポジトリでバージョン管理できるので、現在ではこちらを使用する方がおすすめです。最初に少し設定が必要ですので、使い始めるまでに心理的障壁があるのも事実かと思います。そこで今回はMozReviewの使用方法について紹介します。Guideを元にしています。詳細はそちらを参照して下さい。[:ircnick]のような形で末尾にニックネームを付けておきましょう。Board上ではこのニックネームがユーザー名として表示されます。存在するニックネームは使用できません(代わりにメールアドレスのアカウント名+任意の数字になります)。https://hg.mozilla.org/mozilla-centralで取得して下さい。本記事ではバージョン管理システムとしてMercurialを使用する場合のみを対象としますMozReviewはgitでも使用できるようですが、本記事では対象としていません。Boardにもログインできることを確認してみましょう。Boardのログインページにアクセスすると、自動的にログインすることができます。Boardにログインできたら、画面右上のユーザー名を確認して、先ほど設定したニックネームを使用出来ていることを確認すると良いでしょう。自分がソースコードに対して行った変更をMercurialでreviewboard.mozilla.orgにpushするためには、BugzillaのAPIキーが必要になります。この後のMercurialのセットアップの際に必要になりますので、事前に生成しておきましょう。Keysページで行うことができます。Mercurialの追加セットアップMercurialでMozReviewと連携できるようにするためには、Mercurialに追加の設定が必要になります。bootstrapの中で対話的に行うことができます。前回はMozReviewについての説明は省略したため、それに関するセットアップは飛ばしてしまっているかもしれませんね。mercurial-setupで実行することができます。mercurial-setup後はコンソールに表示される指示に従って必要な項目(自分のフルネーム、メールアドレス、ニックネーム等)をセットアップして行けば良いです。Yes/Noで答えるものについては、基本的には全てYesで良いでしょう。以下の項目については、一度MozReviewを設定してしまえは他の方法でパッチを投稿することは無いでしょうから、1で良いでしょう。以下の項目では、先ほどBugzillaで生成したAPIキーをコピペして入力します。mercurial-setupが正常に終了したら、~/.hgrcを確認して必要な項目が適切に設定されていることを確認します。前回の記事で紹介したように、Firefoxで何かパッチを投稿したい場合は、全てBugzilla上の該当Bugを起点に作業を行います。何か新機能を追加したり、不具合修正を行いたい場合は、まず該当するBugが既に存在するかどうかを確認し、無い場合は新たに自分で新しいBugをfileします。該当Bugでソースコードに対して何か変更を行って、いざMozReviewでパッチを投稿したいとなった場合、まずはMercurialで手元のリポジトリに変更をコミットします。commitこのとき、コミットメッセージの形式に注意しましょう。具体的には以下のような形式にする必要があります。[Bugの概要(一行)]以下、Bugの詳細についての記述...Mercurialでリモートリポジトリにpushする際、上記のコミットメッセージのBug番号から自動的にBugzillaの該当Bugにパッチが投稿されます。末尾にr?ircnickという形式でレビュアーを指定すると、push後に自動的に該当レビュアーにレビューリクエストを投げることもできます。UIから行うこともできますので、必ずしもコミットメッセージに含める必要はありません。以下に、筆者が実際にパッチを投稿した際のコミットメッセージを示します。issue.詳細な議論はBug番号から辿ることができるため、コミットメッセージには必ずしも詳細な記述は必要ないようです。有った方が好ましいとは思いますが、慣れていない場合には、まずはBug番号と一行サマリを適切に記載することに注力すると良いでしょう。ローカルリポジトリへのコミットが完了したら、リモートリポジトリにpushします。UI上で行うことができます。(draft)この状態では、レビューリクエストはまだ公開されておらず、レビュアーにも通知は届いていません。ここでyを入力すると、レビューリクエストが公開され、レビュアーに通知されます。UI上でレビュアーを指定した上でレビューリクエストを公開することも可能です。この場合は下記画面のReviewersでレビュアーを指定した後、Publishを押してレビューリクエストを公開します。Board側のレビューリクエストと正しく紐付けられていることを確認しておくと良いでしょう。exportで確認してみると、以下のようにMozReview-Commit-IDという行が追加されていることに気が付きます。2khX59CotQK...これは後にレビュー結果を受けてパッチを修正する際に必要になります。Boardにpushすることになります。--amendで前回のコミットをやり直す方法でしょう。この方法の場合、コミットメッセージは特に修正しなければ前回のままとなりますので、MozReview-Commit-IDも前回と同じものが使用されます。ローカルリポジトリの修正は上書きされてしまいますが、リモートリポジトリ上では過去のバージョンも管理され、その差分を確認することもできます。Board上でレビュアーのコメントに返信をします。この際も、最後にPublishボタンを押すことを忘れないで下さい。Board上の会話は自動的にBugzillaの該当Bugの方にも同じ内容が投稿されます。レビューが通ったらレビュアーによってパッチが問題ないと判断された場合、r?あるいはr-となっていた部分がr+に変更されます。この状態になったら、前回の記事と同様に、Bugzilla上で「Keywords」欄にcheckin-neededのキーワードを付加して、パッチをチェックインしてもらいます。まとめMozReviewでのFirefoxへのパッチ投稿方法について紹介しました。1451816はGNU/LinuxのWestonという環境でポップアップウィンドウのボタンを操作できないという問題です。本質的な修正は他のBugで行う必要があり、投稿しているパッチは必ずしも本体に入れるつもりの無いad-hocなパッチです。このようなパッチでも、アップストリームに報告しておけば同じ問題で困っている人の助けになるかもしれませんし、本質的な修正のヒントになる可能性もあります。自分のパッチに価値があるかないかは出してみないと分かりませんので、皆さんも臆することなくどんどんパッチを提出してみてはいかがでしょうか。4.0とGFDLのデュアルライセンスで自由に利用できます。クリアコードはプログラミングが楽しいソフトウェア開発者を1名募集しています。クリアコードは「クリアコードをいい感じにする人」を1名募集しています。クリアコードはフリーソフトウェア開発で培った技術力を提供しています。Thunderbird)とRubyとGroonga(全文検索)に関連した開発を得意としています。