Practical Bug Reporting

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 いよいよ困ったら英語は忘れてください

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? ご静聴ありがとうございました

Practical Bug Reporting

by charsbar on Sep 12, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

2 Embeds 129

Statistics

Practical Bug Reporting — Presentation Transcript

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