はじめに
MozillaによるFirefoxやThuderbirdの開発は基本的にBugzillaのやり取りにより行われています。そのため、GitHubでのやり取りに比べとっつきにくい印象がどうしても拭えません。MozillaのBugzillaでの開発プロセスを一通り行ったのでまとめます。 前回の記事 は「macOS Printing」や「macOS printToFile PDF」などで検索して引っかかったBugにsubmitしたパッチを解説しました。 今回はそのパッチをsubmitしてmozilla-centralにコミットされるまでの流れを追います。
Bugzillaでのやり取り
Bugzillaでは以下の図のようなやり取りを通じて開発が進められます。1
Mozillaの開発では基本的にパッチは何らかのBugに紐づけられるものです。 Bugを立てないことにはパッチのレビューをしてもらうことはできません。
準備
まずは直面した問題がBugになっていないかを確認します。まずはキーワードにより検索します。該当のBugがあればこのBugの作業がしたいというコメントを残して権限のある人にAssignしてもらいます。
以降ではprintToFile is busted on Mac | Mozilla Bugzillaでのやり取りを元に解説していきます。
パッチの作成
Bugにアサインされるといよいよパッチをsubmitするための準備が整います。 StatusはNEWのままで問題ないようです。
レビューに出す
MozillaのBugzillaでのレビューはreviewして欲しい人に対してreviewフラグを立てることにより始まります。また、レビューフラグを立ててもreviewフラグが立っている人が忙しいなどの理由で別の人にreviewフラグが移されることもあります。printToFile is busted on Mac | Mozilla Bugzillaでのやり取りではComment 19のようにreviewフラグが別に人に移譲されています。
パッチのコミット
レビューをめでたく通過した場合は、mozillaのリポジトリにコミットしてもらう必要があります。通常はコミット権はないのでcheckin-neededキーワードをkeywordに追加します: https://bugzilla.mozilla.org/show_bug.cgi?id=675709#c19
このcheckin-neededキーワードが追加されていないとレビューには通っても永久にmozillaのリポジトリにコミットされないことに注意してください。
Mozillaの古いWikiではこの段階で既にmozilla-centralへのコミットがなされると書かれていることがありますが、現在はmozilla-inboundというリポジトリにまずはコミットされます。
printToFile is busted on Mac | Mozilla Bugzillaでのやり取りでは一旦review+がもらえましたが、inboundでのビルド失敗により差し戻されています。
執筆現在のinboundサーバーのmacOSのワーカーが10.7のため、未定義となってしまった定数が出てしまったようです。
ステータスがFIXEDになればめでたく該当Bugでの作業は終了です。
まとめ
MozillaのBugzillaでの作業をどのように行うかをprintToFile is busted on Mac | Mozilla BugzillaのBugを元に解説を試みました。GitHubによる開発プロセスになれた開発者にはとっつきにくい印象がありますが、GitHubができるよりも前から開発が続いているソフトウェアの開発プロセスを体験してみるのはいかがでしょうか。
