Practical Bug Reporting
Upcoming SlideShare
Loading in...5
×
 

Practical Bug Reporting

on

  • 3,227 views

a talk at YAPC::Asia 2009

a talk at YAPC::Asia 2009

Statistics

Views

Total Views
3,227
Views on SlideShare
3,093
Embed Views
134

Actions

Likes
1
Downloads
8
Comments
0

3 Embeds 134

http://d.hatena.ne.jp 127
http://www.slideshare.net 6
http://geechscamp.lovepop.jp 1

Accessibility

Categories

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.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
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 テスターのみなさん
  •  
  • http://cpantesters.org/
  • 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 も見習っている
  • http://testanything.org/
  • 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 種類はいろいろ
  • http://wiki.cpantesters.org/wiki/SmokeTools
  • Useful if you have much to test 大量のモジュールをテストしたい人には便利
  • Testers wanted テスターは多いに越したことはありません
  • especially if you have minor environments/ older perls マイナーな環境をお持ちの方はぜひご協力を
  • Does this really work? ほんとにこれ役に立つの?
  • Yes! 立ちますよ
  • cpantesters.org 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 でもご心配なく
  • OUR ENGRISH AR TEH MUCH BETTR THAN THEIR JAPANEEZ 渡した血の絵以後の方がまだ増しですから
  • 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 いつ何をどんな風にやったら、こうなった、と
  • translate.google.com 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 リポジトリの位置も確認しておいてください
  • search.cpan.org 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> @rt.cpan.org ディストリビューション名は適宜埋めてください
  • 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.org 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? ご静聴ありがとうございました