もずはっく日記(2005年12月)

bugzillaとは
初回投稿日時: 2005年12月14日04時39分40秒
カテゴリ: Firefox Mozilla Core Suite Thunderbird
SNS: Tweet (list)

もう、面倒だし、時間が勿体ないので総括。

bugzillaに報告するということは、(一時的に)開発者の一員となるということである。 だから、bugzillaのスタッフからは最初の報告の内容にはクオリティが求められる。 どうすれば確実に、シンプルにバグを再現できるのか、なぜバグと言えるのか、なぜ修正されるべきなのか、修正されればどういったメリットがあるのか等々、スタッフが疑問に思うことがないように報告できることが理想である。

だが、実際にはスタッフによる報告でもお互い、環境に違いがあるのでバグが再現したり、しなかったりする。スタッフ以外の報告者ならなおさら意思の疎通には難しいものがある。そのために、バグの再現方法の確認等、不足している情報について問い合わせが発生する。報告者は当然これに答える義務がある。反応が無いなら、そのバグはすぐに閉じて、次のバグの作業に入ることになる。

報告しました、はいあとはよろしく。というのはbugzillaでは成り立たない。スタッフから要請があればそれに応える義務も発生するのだ。気軽に報告されてもスタッフが余計な後始末をする必要が増えるだけなのである。

これだけ聞くと、bugzillaというのは近寄りがたいものと思えるかもしれない。実際その通りである。bugzillaへの報告の際に事前のテストとして、三日以内にビルドされたNightlyビルドでの再現テストもガイドラインで明記されているように、通常のユーザからすれば、その敷居は確実に高いものなのだ。(検索は敷居を低くしたいものだが、結局ステータスを理解しなくてはいけないなど、下げれない敷居がどうしても存在している。)

また、bugzillaのスタッフは虫がよいと思われるかもしれない。そうかもしれないが、わがままでそう言いたいのではない。bugzillaは日本も本家も既にフル稼働している。未処理のバグを検索してみればその処理が追いついていないことは簡単に分かる。つまり、解決に近いもの、重要度の高いものから順に処理していくことになる。自然と、マンパワーの不足から、報告者という参加者にもクオリティを求めなくてはいけない事態に陥っているというのが実情である。だからクオリティの低い、重要度も低そうなバグは捨てるしか無いのだ。

件の報告者は、質問に応じなかった、また、そもそも普通は用途を疑問に思うような情報を盛り込まずに、報告してきた(そもそも報告した文面から見て、bugzillaのバグ報告ガイドラインから大きく逸脱した質の低い報告である)。機密で用途を公開できないなら、最初からバグとして報告すべきではないし、報告後も、一言その旨の返答があって然るべきである。このような状況下で、「金儲けに使うんやからよろしく。」などと発言したらそれこそただのバカである。

本当に、bugzilla関係のドキュメント整備を行わないといけない。しかし、日々バグの処理、パッチの作成、パッチのテスト、レビュー、そして事務処理に追われているというのが現状である。