Upload
charsbar
View
3.328
Download
2
Embed Size (px)
DESCRIPTION
a talk at YAPC::Asia 2009
Citation preview
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?
ご静聴ありがとうございました