はじめてのもじらのばぐじらの歩き方
DESCRIPTION
Mozilla勉強会@東京 5thのLTにて発表した資料。一部追記および再構成している個所があります。TRANSCRIPT
はじめての もじらのばぐじらの
歩き方
saneyuki_s
今回の発表はかなり経験に依存しているため 実際の点についてはその都度
Mozillaの方に質問して 得た情報がベース
※注意
平民でも安心して歩けるように
MozillaのBugzillaの ローカルールの 情報共有をしたい
※ツッコミ歓迎
アカウント編
Bugzillaのアカウントは実名制?
• バグ報告とかコメントなら 実名の必要性は無いらしい
–現在、Bugzillaのガイドラインにも 特に記述はない
• パッチの提出をすると実名の必要がある?
–特別決まりはない。
–欧州の方の人でずっとHNでパッチを コミットしてる人もいる
他人のバグを編集する権限がある
• 「ある程度バグを報告して、そのバグ由来のパッチがある程度コミットされると 権限がもらえる」らしい
–「SpiderMonkeyのバグを 100個くらい登録してたらもらえた」
–「自分でパッチは書いていなくても、 『バグだと認められて修正される』報告を 10個くらいすると貰える」
……など、体験談多数。
–要は担当者に役に立つと思われれば貰える
実際に 報告してみる編
(※重複の有無など基本的なことは割愛)
ちゃんとカテゴライズしましょう
• UNCONFIRMEDのまま放置される危険が減る
• トラッキングバグに関連付けましょう
• 関係ありそうなところに関連付け
–間違ってるとたらいまわし
• 立てたバグのBlock欄に登録
–トラッキングバグは[meta]とか ”Tracking”などの単語で検索すれば出てくる
テストケースを添付しましょう
• バグ修正への近道
– Piroさんもこの間言ってた!
• 再現するのに必要最小限なコードでおk
– Mochitestとか頑張らなくても大丈夫
• 頑張った方が修正されるかもしれません
• 再現状況が特定できない& 再現手順がややこしい場合最悪スクショで
–画像でも大丈夫です
– OggでもWebMでも問題ないみたいです
Piroさんも言ってた!
http://piro.sakura.ne.jp/latest/blosxom/mozilla/firefox/2011-01-10_transitionend.htm
○○はどうするべき?
○○はどうするべき?
• Whitebord • Keyword
– そもそも指定すべき言葉が仕方がわからないです – 他のバグの動向から、 わかるようになると重宝されるようになるとか
• Blocking • Priority • Target Milestone
– 「基本的に触るな」ってBugzillaのガイドラインに 書いてあった。
– でも「これ直さないとヤバくね?」なレベルの割に 放置プレイくらってるバグはBlockerとかにして判断を 仰ぐべきかも。(後で怒られるリスクを覚悟)
ぶっちゃけ 実際の所どうなのよ編
大切なことはIRCで すべて決まっていて
bugzillaのコメントによる議論って 参考と同義じゃないの?
ウワサ
実際
• IRC+dev.planning+Bugzilla の三本柱 – Bugzillaはバグごとの主題について議論
– dev.planningで全体の方向性について議論
– IRCは実装自体の詳細について議論
• IRCもdev.planningも公開されてるので 議論に参加も可能