Practical Bug Reporting

Sep 11, 2009＠ YAPC::Asia 2009

Kenichi Ishigaki (charsbar)

Part ICPAN is well teste

d

CPAN と品質保証

Let me give you a few numbers

まずは数字をいくつか紹介しましょう

(inspired bythe fabulous talk

by barbie)

海外の YAPC で紹介されていたネタのパクリだけど

5067318

The total number oftest reportssince 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 strongtesting 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 have7600+ authors

18500+ distributions72000+ modules

これだけの叡智が集まっているのはすごいこと

Our strengthis not from

the sheer number

でも、大事なのは単純な数の多さではありません

What really mattersis the number oftested modules

品質保証されているかどうかがポイントです

Back to the figures

で、先ほどの数字を見てみましょう

5067318 total4255953 passes

全部のテストが通っているわけではありません

Only eightout of ten

are healthy

成功率は 8 割程度です

Eventuallyyou'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 rep

ort

テストレポートの送り方

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 notthat difficult

そんなに難しいことではないです

You also can set up a smoker

スモーカーを用意してもよいでしょう

CPAN::Reporter::SmokerPOE::Component::CPAN::YACSmoke

POE::Component::SmokeBoxPOE::Component::SmokeBox::Recent

App::SmokeBox::Mini

種類はいろいろ

http://wiki.cpantesters.org/wiki/SmokeTools

Useful if you havemuch to test

大量のモジュールをテストしたい人には便利

Testers wanted

テスターは多いに越したことはありません

especially ifyou have minorenvironments/

older perlsマイナーな環境をお持ちの方はぜひご協力

を

Does thisreally work?

ほんとにこれ役に立つの？

Yes!

立ちますよ

cpantesters.org offersa personalized feed

CPAN Author向けのフィードもあります

However

ただ

Not everyone can(or is allowed to)

send reports

もちろん誰もがレポートしてくれるわけではありません

Not everyonecares Testers

レポートを気にしない作者もいます

Bugs are slipped inwhere tests don't c

over

テストがカバーしてない部分については無力

Not everythinghas enough tests

テスト足りないモジュールもありますからね

100% test coverage

is not enough

カバレッジ 100%だからって安心できない

It may lackborder tests

境界テストとか

It may havebugs found onlyin stress tests

ストレスかけないと出てこないバグとか

It may havedesign flaws

設計がおかしいとか

Though this isnot a bug

これはバグじゃありませんけど

Even well-tested modules may be bro

ken sometimes

しっかりテストされてるモジュールでも壊れることはあります

Even aftersuccessful installa

tion

しかもインストールに成功したあとで

Conflicts

外部依存を持つ CPAN モジュールの宿命

with external libraries

別の外部ライブラリに影響されたり

with older installation

旧版のファイルが悪さをすることもあります

(pluggable modules sometimes

suffer from this)

プラガブルなモジュールにありがち

Dependency onbugs of others

ほかのモジュールのバグに依存していたとか

Backward-incompatible

API changes of others

ほかのモジュールの API が変わったとか

May eventually be found by the Tester

s

そのうちテスターが見つけてくれるかもしれません

What else should we do?

こういう場合はどうするのがよいでしょう

Part III (before)

Filing a bug report

そう、バグレポートです

Hold on

でも、ちょっと待って

perldoc perlbug

There're several thingsto 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 onesmay have a fix

for you

最新版では直っているかもしれませんから

Isn't it a feature,or a known limitati

on?

バグじゃなくて仕様だったり既知の問題だったりしませんか？

Read the pod, Changes,or comments in the sour

ce

PODとか更新履歴とかソースのコメントとか確認してみましょう

Isn't it a bugof 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 Testerswill test it for us

テストさえあれば検証をテスターに丸投げすることもできます

Only tests can ensureyou'll never seethe bug again

同じ問題を何度もレポートしたくないならぜひ

Can you writea patch to fix?

パッチは用意できますか？

A nice patch willalways be welcome

見つけた方が直せればそれにこしたことはありません

What about a report message?

レポートはどう書けばよいのかって？

English isour second

common language

たしかに共通語は英語です

Don't worry

でもご心配なく

OUR ENGRISH ARTEH MUCH BETTR

THAN THEIR JAPANEEZ

渡した血の絵以後の方がまだ増しですから

Descriptive title

タイトルだけはわかりやすく

Make it clearwhat is broken

どこが壊れてるかを明記してください

Which function?Which test?

With what error?

どの関数、どのテストがおかしくて、どんなエラーが出る、等々

Better if you can provide concise description of th

e issue

本文でもう少し詳しく説明できるといいですね

What happenedwhen you didwhat and how

いつ何をどんな風にやったら、こうなった、と

translate.google.comand such may help yo

u

オンラインの翻訳ツールとか使うのもアリ

Rememberyou have

the last resort

いよいよ困ったら英語は忘れてください

Perl

This is our firstcommon language

これこそが私たちの共通語です

That's why you shouldwrite a test and/or a pa

tch

だからこそテストやパッチを書きましょう、と

Part IV Choosing destinat

ion

送り先を選ぶ

Now you haveall the necessary

information to report

これで必要な情報はあらかた揃ったはずです

To where should youfile the report?

さて、どこへレポートしましょうか？

RT?

RT ？

Not ReTweet

ReTweet の略じゃありませんよ

CPAN's defaultRequest Tracker

CPAN標準のバグトラッカーです

by Best Practical Solutions

みなさんご存じですよね

What you see isa bit older version

(3.6 HEAD)

CPAN で利用されているのはちょっと古い

Latest 4.0 isbased on Jifty

最新版は Jiftyベースになります

Ask Jessewhen it's out :)

いつリリースされるかは社長におたずねください

Also checkLorzy talkby clkao

clkao の Lorzy話も ( たぶん ) RT 4.0 がらみ

Anyway

それはさておき

Not everyone uses RT

誰もが RT を使っているわけではありません

google codesourceforge

githubtrac

ほかのトラッカーを使っている人も結構います

Read the pod

たいてい PODに書いてありますが

META.ymlmay tell yousometimes

META.yml に明記されていることも

OK, now you know where to file

どこを見ればいいかわかったら

Make sure to seeif similar bugs

have been reportedor not

似たようなバグが登録されていないか確認

Avoid spamming

同じようなレポートがたくさん届くのは迷惑

See also where istheir repository

リポジトリの位置も確認しておいてください

search.cpan.orgmay also tell you

sometimes

これも CPAN検索サイトに明記されているかも

External trackersusually tightly-knit

with their repository

外部のトラッカーはたいていリポジトリ連動

Commit logs may befound while googling

ググるとコミットログが出てくる場合も

Why do we need tofind a repository?

なんでリポジトリを探すのか？

Your bug mayhave been fixedin the repository

リポジトリでは直っている場合も少なくないから

Not alwaysin the trunk

though

場合によっては修正用のブランチも見つかる

Mailing listmay also help

メーリングリストも要チェックですね

Searchable archives

will be your friend

アーカイブ検索できるところを覚えておくと便利

Anyway

ともかく

Time to file it at last

実際にバグレポートを出してみましょう

Part VRT 101

RT の使い方

The easiest way isto send an email to

一番簡単なのはメールで登録するやり方

bug-<distribution-name> @rt.cpan.org

ディストリビューション名は適宜埋めてください

Attach your test and patch

テストやパッチは添付ファイルで

If you wantfiner control

もう少し細かい指定をしたい場合は

Try web interface

Web インタフェースを使うのもアリです

You need to identify

yourself to login

スパム対策で身元を確認できるものが必要

BitcardPAUSEOpenID

Report a new bug

新しいバグを報告する、という項目から

Severity

重要度

Mark as Wishlist if it's not

about a bug

要望の場合は自分でチェックした方がいいかも

Broken in, Fixed in

バグっているバージョンと直っているバージョン

You usually don'tneed to care

ふつうは気にする必要ありません

May help fora long-standing bu

g

調べておいてもらえると作者としては楽

Everything is OK?

本文やタイトル、添付ファイルの準備ができたら

Create

送信

Notification will besent to all the

(co-)maintainers

登録するとすべてのメンテナに通知が行きます

When you receivea 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 resolveyour ticket by half

チケットを半分だけ閉じるとかできませんし

Not all of yourpatch may be appli

cable

パッチをすべて適用できるとも限りません

Severity varies

優先順位も違ったりします

May be turned downjust because it's mixe

d

複数のレポートが混じっているというだけで拒否られることも

Split your report, patch, test, and wh

atever

パッチやテストはなるべく意味のあるまとまりごとにわけてください

One bug, one report

バグひとつに対してレポートひとつが原則

with one or more tests

テストが複数にわかれるのはかまいません

That isn't considered spamming

適切に分割されたレポートが続くのはスパムとはみなされません

Well, usually

ふつうは、ですけどね

Part VIIf 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 YAPCmay 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 isthe most fruitful w

ay

ふつうはこれがもっとも実りが多い

No

いや、これも正確ではないですね

This is notthe 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 blogtwitter

other mailing listwhatever

ブログ書いてたり、ぼそぼそつぶやいていたり

Ask in p5p

ほんとに大事なモジュールならp5p で聞いてみるといい

Wait and see

人事を尽くして天命を待つもよし

Or write your own

さっさと自前のモジュールをこさえるもよし

Part VII Conclusion

まとめ

Don't be shy

黙っていては始まりません

Your reports will make our world bett

er

CPAN をよりよいものにするためにはみなさんのレポートが不可欠です

But report it to the right places

ただ、レポートは適切な場所にお願いします

Reporting a bugin a blog entry

is considered harmful

ブログに書いておしまい、というのはよくない

miyagawa さんに嫌われます

If you do, at leastupdate your entriesafter the bug is fixed

ブログに書くなら、せめてバグが直ったら

その旨書き足さないと

Otherwise, you'll be

a source of FUD

FUDのもとになりますからね

Writing another entry doesn't help

ほかのエントリ書くだけでは足りません

People findyour entry

via search engines

検索エンジンから来た人は

Nobody reads morethan the page

they just googled

問題があったページしか読んでくれません

Ok, that's all

以上

Thank you&

Questions?

ご静聴ありがとうございました