Practical Bug Reporting
Upcoming SlideShare
Loading in...5

Practical Bug Reporting



a talk at YAPC::Asia 2009

a talk at YAPC::Asia 2009



Total Views
Views on SlideShare
Embed Views



3 Embeds 134 127 6 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Practical Bug Reporting Practical Bug Reporting Presentation Transcript

  • Practical Bug Reporting Sep 11, 2009 @ YAPC::Asia 2009 Kenichi Ishigaki (charsbar)
  • Part I CPAN is well tested CPAN と品質保証
  • Let me give you a few numbers まずは数字をいくつか紹介しましょう
  • (inspired by the fabulous talk by barbie) 海外の YAPC で紹介されていたネタのパクリだけど
  • 5067318
  • The total number of test reports since 1999 この 10 年で届いたテストレポートの数です
  • And its breakdown 内訳は
  • 4255953 passes 503541 fails 119277 NAs 188547 unknowns
  • CPAN is well tested CPAN ってほんとによくテストされているんです
  • By whom? でも誰がテストしているの?
  • Kudos to the CPAN Testers CPAN テスターのみなさん
  • 250000+ reports/month on average (2008/08-2009/08) この 1 年の月間平均レポート数 25 万
  • 339884 reports in Aug 2009 (against 1708 uploads) 先月は 30 万件越えてます
  • 166 Testers 先月レポートを送ってくださった方は 166 人
  • including bots (smokers) bot 込みですが
  • We have a strong testing culture Perl の強みはテストの文化です
  • Test Anything Protocol 最近はほかの LL も見習っている
  • Lots of testing tools テスト関連ツールの数も半端ない
  • 500 Test distributions (338 Test- and 162 -Test-?) ディストリビューション単位で総計 500 個
  • CPAN is our strength よく CPAN あってこその Perl といわれます
  • We have 7600+ authors 18500+ distributions 72000+ modules これだけの叡智が集まっているのはすごいこと
  • Our strength is not from the sheer number でも、大事なのは単純な数の多さではありません
  • What really matters is the number of tested modules 品質保証されているかどうかがポイントです
  • Back to the figures で、先ほどの数字を見てみましょう
  • 5067318 total 4255953 passes 全部のテストが通っているわけではありません
  • Only eight out of ten are healthy 成功率は 8 割程度です
  • Eventually you'll be hit by a bug or two いつかはバグに当たることでしょう
  • What should we do? そんなとき、どうするか
  • Three wise monkeys 東照宮の三猿、ご存じですよね
  • See no evil 見ざる
  • Listen no evil 聞かざる
  • Speak no evil 言わざる
  • Good for children 子どもを守るための方便だそうですが
  • We should know better 我々はもうちょっと大人です
  • Monkey patch? 猿といえば、モンキーパッチという手もあります
  • *Some::Module::method = sub { ... }; こんなの
  • Can't be helped sometimes これも、どうしようもないときには便利ですが
  • Not for today 根本的な解決にはなりません
  • Then what we should do? では、どうするか
  • Report your experience 「ホウ・レン・ソウ」ご存じですよね?
  • But how, and to where? でも、どこに、どうやって ?
  • Part II Sending a test report テストレポートの送り方
  • The easiest way to get involved いちばん簡単なやり方
  • Set up a reporter レポーターをセットアップする
  • cpan CPAN::Reporter
  • Launch the CPAN shell インストールが済んだら CPAN シェルから
  • cpan> o conf init test_report あとはいくつか設定を指定するだけ
  • It's not that difficult そんなに難しいことではないです
  • You also can set up a smoker スモーカーを用意してもよいでしょう
  • CPAN::Reporter::Smoker POE::Component::CPAN::YACSmoke POE::Component::SmokeBox POE::Component::SmokeBox::Recent App::SmokeBox::Mini 種類はいろいろ
  • Useful if you have much to test 大量のモジュールをテストしたい人には便利
  • Testers wanted テスターは多いに越したことはありません
  • especially if you have minor environments/ older perls マイナーな環境をお持ちの方はぜひご協力を
  • Does this really work? ほんとにこれ役に立つの?
  • Yes! 立ちますよ
  • offers a personalized feed CPAN Author 向けのフィードもあります
  • However ただ
  • Not everyone can (or is allowed to) send reports もちろん誰もがレポートして くれるわけではありません
  • Not everyone cares Testers レポートを気にしない作者もいます
  • Bugs are slipped in where tests don't cover テストがカバーしてない部分については無力
  • Not everything has enough tests テスト足りないモジュールもありますからね
  • 100% test coverage is not enough カバレッジ 100% だからって安心できない
  • It may lack border tests 境界テストとか
  • It may have bugs found only in stress tests ストレスかけないと出てこないバグとか
  • It may have design flaws 設計がおかしいとか
  • Though this is not a bug これはバグじゃありませんけど
  • Even well-tested modules may be broken sometimes しっかりテストされてるモジュールでも 壊れることはあります
  • Even after successful installation しかもインストールに成功したあとで
  • Conflicts 外部依存を持つ CPAN モジュールの宿命
  • with external libraries 別の外部ライブラリに影響されたり
  • with older installation 旧版のファイルが悪さをすることもあります
  • (pluggable modules sometimes suffer from this) プラガブルなモジュールにありがち
  • Dependency on bugs of others ほかのモジュールのバグに依存していたとか
  • Backward-incompatible API changes of others ほかのモジュールの API が変わったとか
  • May eventually be found by the Testers そのうちテスターが見つけてくれるかもしれません
  • What else should we do? こういう場合はどうするのがよいでしょう
  • Part III (before) Filing a bug report そう、バグレポートです
  • Hold on でも、ちょっと待って
  • perldoc perlbug
  • There're several things to check before filing a bug report その前にすることがあるんです
  • The version of perl Perl のバージョン
  • perl -V
  • Note the uppercase V コンパイル時の設定とか知らせるのは結構大切
  • The version of modules モジュールのバージョン
  • perl -MModule::Name -e 'print $Module::Name::VERSION'
  • perl -e 'use Module::Name 999999'
  • The latest ones may have a fix for you 最新版では直っているかもしれませんから
  • Isn't it a feature, or a known limitation? バグじゃなくて仕様だったり 既知の問題だったりしませんか?
  • Read the pod, Changes, or comments in the source POD とか更新履歴とかソースのコメントとか確認してみましょう
  • Isn't it a bug of your software? 自分のソフトが悪かったりしませんよね?
  • Write a test なるべく小さなテストを書いてみましょう
  • If you can't reproduce the bug, 見つけた人が再現できないようでは
  • the maintainers probably can't, too メンテナも調べようがありません
  • If we have a test, at least Testers will test it for us テストさえあれば検証を テスターに丸投げすることもできます
  • Only tests can ensure you'll never see the bug again 同じ問題を何度もレポートしたくないならぜひ
  • Can you write a patch to fix? パッチは用意できますか?
  • A nice patch will always be welcome 見つけた方が直せれば それにこしたことはありません
  • What about a report message? レポートはどう書けばよいのかって?
  • English is our second common language たしかに共通語は英語です
  • Don't worry でもご心配なく
  • Descriptive title タイトルだけはわかりやすく
  • Make it clear what is broken どこが壊れてるかを明記してください
  • Which function? Which test? With what error? どの関数、どのテストがおかしくて、 どんなエラーが出る、等々
  • Better if you can provide concise description of the issue 本文でもう少し詳しく説明できるといいですね
  • What happened when you did what and how いつ何をどんな風にやったら、こうなった、と
  • and such may help you オンラインの翻訳ツールとか使うのもアリ
  • Remember you have the last resort いよいよ困ったら英語は忘れてください
  • Perl
  • This is our first common language これこそが私たちの共通語です
  • That's why you should write a test and/or a patch だからこそテストやパッチを書きましょう、と
  • Part IV Choosing destination 送り先を選ぶ
  • Now you have all the necessary information to report これで必要な情報はあらかた揃ったはずです
  • To where should you file the report? さて、どこへレポートしましょうか?
  • RT? RT ?
  • Not ReTweet ReTweet の略じゃありませんよ
  • CPAN's default Request Tracker CPAN 標準のバグトラッカーです
  • by Best Practical Solutions みなさんご存じですよね
  • What you see is a bit older version (3.6 HEAD) CPAN で利用されているのはちょっと古い
  • Latest 4.0 is based on Jifty 最新版は Jifty ベースになります
  • Ask Jesse when it's out :) いつリリースされるかは社長におたずねください
  • Also check Lorzy talk by clkao clkao の Lorzy 話も ( たぶん ) RT 4.0 がらみ
  • Anyway それはさておき
  • Not everyone uses RT 誰もが RT を使っているわけではありません
  • google code sourceforge github trac ほかのトラッカーを使っている人も結構います
  • Read the pod たいてい POD に書いてありますが
  • META.yml may tell you sometimes META.yml に明記されていることも
  • OK, now you know where to file どこを見ればいいかわかったら
  • Make sure to see if similar bugs have been reported or not 似たようなバグが登録されていないか確認
  • Avoid spamming 同じようなレポートがたくさん届くのは迷惑
  • See also where is their repository リポジトリの位置も確認しておいてください
  • may also tell you sometimes これも CPAN 検索サイトに明記されているかも
  • External trackers usually tightly-knit with their repository 外部のトラッカーはたいていリポジトリ連動
  • Commit logs may be found while googling ググるとコミットログが出てくる場合も
  • Why do we need to find a repository? なんでリポジトリを探すのか?
  • Your bug may have been fixed in the repository リポジトリでは直っている場合も少なくないから
  • Not always in the trunk though 場合によっては修正用のブランチも見つかる
  • Mailing list may also help メーリングリストも要チェックですね
  • Searchable archives will be your friend アーカイブ検索できるところを覚えておくと便利
  • Anyway ともかく
  • Time to file it at last 実際にバグレポートを出してみましょう
  • Part V RT 101 RT の使い方
  • The easiest way is to send an email to 一番簡単なのはメールで登録するやり方
  • bug-<distribution-name> ディストリビューション名は適宜埋めてください
  • Attach your test and patch テストやパッチは添付ファイルで
  • If you want finer control もう少し細かい指定をしたい場合は
  • Try web interface Web インタフェースを使うのもアリです
  • You need to identify yourself to login スパム対策で身元を確認できるものが必要
  • Bitcard PAUSE OpenID
  • Report a new bug 新しいバグを報告する、という項目から
  • Severity 重要度
  • Mark as Wishlist if it's not about a bug 要望の場合は自分でチェックした方がいいかも
  • Broken in, Fixed in バグっているバージョンと直っているバージョン
  • You usually don't need to care ふつうは気にする必要ありません
  • May help for a long-standing bug 調べておいてもらえると作者としては楽
  • Everything is OK? 本文やタイトル、添付ファイルの 準備ができたら
  • Create 送信
  • Notification will be sent to all the (co-)maintainers 登録するとすべてのメンテナに通知が行きます
  • When you receive a reply or a question 返信があったらメールが届きます
  • Reply to the notification さらに返信する場合はメーラから返信すれば OK
  • Or login to reply もちろんログインしてから返信してもいいです
  • When the bug is resolved 解決したバグについてはここに並びます
  • or unfortunately rejected 残念ながら拒否されたレポートはこちら
  • Spams will be deleted スパムは単に削除されます
  • Don't file a comprehensive report to fix multiple bugs 複数のバグをいっぺんに直すような パッチは送らないこと
  • We can't resolve your ticket by half チケットを半分だけ閉じるとかできませんし
  • Not all of your patch may be applicable パッチをすべて適用できるとも限りません
  • Severity varies 優先順位も違ったりします
  • May be turned down just because it's mixed 複数のレポートが混じっているというだけで拒否られることも
  • Split your report, patch, test, and whatever パッチやテストはなるべく意味のある まとまりごとにわけてください
  • One bug, one report バグひとつに対してレポートひとつが原則
  • with one or more tests テストが複数にわかれるのはかまいません
  • That isn't considered spamming 適切に分割されたレポートが続くのは スパムとはみなされません
  • Well, usually ふつうは、ですけどね
  • Part VI If you're in a hurry 急ぎの場合は
  • It's nice to report to a tracker 全体のことを思えばバグトラッカーに 報告するのが一番です
  • Everyone can track it down later 誰もがあとから追跡できますし
  • Everyone can know what, why and how 誰もが問題と解決策を把握できます
  • However ただし
  • It's not the fastest way これは最速の解決策ではありません
  • If you're in a hurry もし本当に急いでいるなら
  • or want to make sure あるいは確実に直しを入れてもらいたいなら
  • Ask the author in person 作者に直接連絡をとりましょう
  • via IRC IRC 経由でもいいですし
  • via email 本人宛のメールでもかまいません
  • Events like YAPC may help このようなイベントで話しかけるのも手ですね
  • It certainly has downsides このやり方には欠点もあります
  • No tracker バグトラッカーには記録されません
  • unless you file it later あとから記録として登録しない限りは、ですが
  • There may be few (or none) who can help you まわりに助けてくれる人がいない 可能性もあります
  • IRC has its own local rules IRC には独自のルールがあるのも要注意
  • Don't ask to ask 「質問していいですか」なんて聞くな、とか
  • Use nopaste 長いコードを貼り付けるな、とか
  • But it usually is the most fruitful way ふつうはこれがもっとも実りが多い
  • No いや、これも正確ではないですね
  • This is not the last resort in fact 実は究極の手段が残っています
  • Be a committer コミッタになってしまうことです
  • coderepos, pugs, jifty, github, alias...
  • Forgiveness over permission 許可より寛容
  • Everyone was a beginner at first 誰もが最初は初心者です
  • Commits can be reverted 変なコミットは差し戻せますからご心配なく
  • Better if we have more committers コミッタが増えてくれることの方が大事
  • Ask for a commit bit コミット権がほしいとお願いするか
  • Or show something to be committed コミットするに足るものを見せること
  • Learn local rules ローカルルールを確認したら
  • Start commmitting コミットを始めましょう
  • Consult core developers if you make a significant change 大きな変更を入れたいときは要相談
  • The author is unreachable? どうしても作者がつかまらない?
  • Just forget abondoned modules そんなモジュールのことは忘れるのが一番
  • Or find the author in any way どうしてもなんとかしたいなら作者を探しましょう
  • via POD POD に連絡先が書いてあるかもしれませんし
  • via default <id> CPAN のデフォルトメールに 投げてみる手もあります
  • Just google it ググればその人の他の活動にヒットするかも
  • personal blog twitter other mailing list whatever ブログ書いてたり、ぼそぼそつぶやいていたり
  • Ask in p5p ほんとに大事なモジュールなら p5p で聞いてみるといい
  • Wait and see 人事を尽くして天命を待つもよし
  • Or write your own さっさと自前のモジュールをこさえるもよし
  • Part VII Conclusion まとめ
  • Don't be shy 黙っていては始まりません
  • Your reports will make our world better CPAN をよりよいものにするためには みなさんのレポートが不可欠です
  • But report it to the right places ただ、レポートは適切な場所にお願いします
  • Reporting a bug in a blog entry is considered harmful ブログに書いておしまい、というのはよくない
  • miyagawa さんに嫌われます
  • If you do, at least update your entries after the bug is fixed ブログに書くなら、せめてバグが直ったら その旨書き足さないと
  • Otherwise, you'll be a source of FUD FUD のもとになりますからね
  • Writing another entry doesn't help ほかのエントリ書くだけでは足りません
  • People find your entry via search engines 検索エンジンから来た人は
  • Nobody reads more than the page they just googled 問題があったページしか読んでくれません
  • Ok, that's all 以上
  • Thank you & Questions? ご静聴ありがとうございました