• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Practical Bug Reporting

Practical Bug Reporting



a talk at YAPC::Asia 2009

a talk at YAPC::Asia 2009



Total Views
Views on SlideShare
Embed Views



2 Embeds 132

http://d.hatena.ne.jp 126
http://www.slideshare.net 6



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 テスターのみなさん
    • 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 でもご心配なく
    • 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? ご静聴ありがとうございました