Your SlideShare is downloading. ×
0
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::Smoke...
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? ご静聴ありがとうございました
Upcoming SlideShare
Loading in...5
×

Practical Bug Reporting

2,264

Published on

a talk at YAPC::Asia 2009

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,264
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
9
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Transcript of "Practical Bug Reporting"

  1. 1. Practical Bug Reporting Sep 11, 2009 @ YAPC::Asia 2009 Kenichi Ishigaki (charsbar)
  2. 2. Part I CPAN is well tested CPAN と品質保証
  3. 3. Let me give you a few numbers まずは数字をいくつか紹介しましょう
  4. 4. (inspired by the fabulous talk by barbie) 海外の YAPC で紹介されていたネタのパクリだけど
  5. 5. 5067318
  6. 6. The total number of test reports since 1999 この 10 年で届いたテストレポートの数です
  7. 7. And its breakdown 内訳は
  8. 8. 4255953 passes 503541 fails 119277 NAs 188547 unknowns
  9. 9. CPAN is well tested CPAN ってほんとによくテストされているんです
  10. 10. By whom? でも誰がテストしているの?
  11. 11. Kudos to the CPAN Testers CPAN テスターのみなさん
  12. 13. http://cpantesters.org/
  13. 14. 250000+ reports/month on average (2008/08-2009/08) この 1 年の月間平均レポート数 25 万
  14. 15. 339884 reports in Aug 2009 (against 1708 uploads) 先月は 30 万件越えてます
  15. 17. 166 Testers 先月レポートを送ってくださった方は 166 人
  16. 19. including bots (smokers) bot 込みですが
  17. 20. We have a strong testing culture Perl の強みはテストの文化です
  18. 21. Test Anything Protocol 最近はほかの LL も見習っている
  19. 22. http://testanything.org/
  20. 23. Lots of testing tools テスト関連ツールの数も半端ない
  21. 24. 500 Test distributions (338 Test- and 162 -Test-?) ディストリビューション単位で総計 500 個
  22. 25. CPAN is our strength よく CPAN あってこその Perl といわれます
  23. 26. We have 7600+ authors 18500+ distributions 72000+ modules これだけの叡智が集まっているのはすごいこと
  24. 27. Our strength is not from the sheer number でも、大事なのは単純な数の多さではありません
  25. 28. What really matters is the number of tested modules 品質保証されているかどうかがポイントです
  26. 29. Back to the figures で、先ほどの数字を見てみましょう
  27. 30. 5067318 total 4255953 passes 全部のテストが通っているわけではありません
  28. 31. Only eight out of ten are healthy 成功率は 8 割程度です
  29. 32. Eventually you'll be hit by a bug or two いつかはバグに当たることでしょう
  30. 35. What should we do? そんなとき、どうするか
  31. 36. Three wise monkeys 東照宮の三猿、ご存じですよね
  32. 37. See no evil 見ざる
  33. 38. Listen no evil 聞かざる
  34. 39. Speak no evil 言わざる
  35. 40. Good for children 子どもを守るための方便だそうですが
  36. 41. We should know better 我々はもうちょっと大人です
  37. 42. Monkey patch? 猿といえば、モンキーパッチという手もあります
  38. 43. *Some::Module::method = sub { ... }; こんなの
  39. 44. Can't be helped sometimes これも、どうしようもないときには便利ですが
  40. 45. Not for today 根本的な解決にはなりません
  41. 46. Then what we should do? では、どうするか
  42. 47. Report your experience 「ホウ・レン・ソウ」ご存じですよね?
  43. 48. But how, and to where? でも、どこに、どうやって ?
  44. 49. Part II Sending a test report テストレポートの送り方
  45. 50. The easiest way to get involved いちばん簡単なやり方
  46. 51. Set up a reporter レポーターをセットアップする
  47. 52. cpan CPAN::Reporter
  48. 53. Launch the CPAN shell インストールが済んだら CPAN シェルから
  49. 54. cpan> o conf init test_report あとはいくつか設定を指定するだけ
  50. 55. It's not that difficult そんなに難しいことではないです
  51. 56. You also can set up a smoker スモーカーを用意してもよいでしょう
  52. 57. CPAN::Reporter::Smoker POE::Component::CPAN::YACSmoke POE::Component::SmokeBox POE::Component::SmokeBox::Recent App::SmokeBox::Mini 種類はいろいろ
  53. 58. http://wiki.cpantesters.org/wiki/SmokeTools
  54. 59. Useful if you have much to test 大量のモジュールをテストしたい人には便利
  55. 60. Testers wanted テスターは多いに越したことはありません
  56. 61. especially if you have minor environments/ older perls マイナーな環境をお持ちの方はぜひご協力を
  57. 62. Does this really work? ほんとにこれ役に立つの?
  58. 63. Yes! 立ちますよ
  59. 64. cpantesters.org offers a personalized feed CPAN Author 向けのフィードもあります
  60. 67. However ただ
  61. 68. Not everyone can (or is allowed to) send reports もちろん誰もがレポートして くれるわけではありません
  62. 69. Not everyone cares Testers レポートを気にしない作者もいます
  63. 70. Bugs are slipped in where tests don't cover テストがカバーしてない部分については無力
  64. 71. Not everything has enough tests テスト足りないモジュールもありますからね
  65. 72. 100% test coverage is not enough カバレッジ 100% だからって安心できない
  66. 73. It may lack border tests 境界テストとか
  67. 74. It may have bugs found only in stress tests ストレスかけないと出てこないバグとか
  68. 75. It may have design flaws 設計がおかしいとか
  69. 76. Though this is not a bug これはバグじゃありませんけど
  70. 77. Even well-tested modules may be broken sometimes しっかりテストされてるモジュールでも 壊れることはあります
  71. 78. Even after successful installation しかもインストールに成功したあとで
  72. 79. Conflicts 外部依存を持つ CPAN モジュールの宿命
  73. 80. with external libraries 別の外部ライブラリに影響されたり
  74. 81. with older installation 旧版のファイルが悪さをすることもあります
  75. 82. (pluggable modules sometimes suffer from this) プラガブルなモジュールにありがち
  76. 83. Dependency on bugs of others ほかのモジュールのバグに依存していたとか
  77. 84. Backward-incompatible API changes of others ほかのモジュールの API が変わったとか
  78. 85. May eventually be found by the Testers そのうちテスターが見つけてくれるかもしれません
  79. 86. What else should we do? こういう場合はどうするのがよいでしょう
  80. 87. Part III (before) Filing a bug report そう、バグレポートです
  81. 88. Hold on でも、ちょっと待って
  82. 89. perldoc perlbug
  83. 90. There're several things to check before filing a bug report その前にすることがあるんです
  84. 91. The version of perl Perl のバージョン
  85. 92. perl -V
  86. 94. Note the uppercase V コンパイル時の設定とか知らせるのは結構大切
  87. 95. The version of modules モジュールのバージョン
  88. 96. perl -MModule::Name -e 'print $Module::Name::VERSION'
  89. 97. perl -e 'use Module::Name 999999'
  90. 98. The latest ones may have a fix for you 最新版では直っているかもしれませんから
  91. 99. Isn't it a feature, or a known limitation? バグじゃなくて仕様だったり 既知の問題だったりしませんか?
  92. 100. Read the pod, Changes, or comments in the source POD とか更新履歴とかソースのコメントとか確認してみましょう
  93. 101. Isn't it a bug of your software? 自分のソフトが悪かったりしませんよね?
  94. 102. Write a test なるべく小さなテストを書いてみましょう
  95. 103. If you can't reproduce the bug, 見つけた人が再現できないようでは
  96. 104. the maintainers probably can't, too メンテナも調べようがありません
  97. 105. If we have a test, at least Testers will test it for us テストさえあれば検証を テスターに丸投げすることもできます
  98. 106. Only tests can ensure you'll never see the bug again 同じ問題を何度もレポートしたくないならぜひ
  99. 107. Can you write a patch to fix? パッチは用意できますか?
  100. 108. A nice patch will always be welcome 見つけた方が直せれば それにこしたことはありません
  101. 109. What about a report message? レポートはどう書けばよいのかって?
  102. 110. English is our second common language たしかに共通語は英語です
  103. 111. Don't worry でもご心配なく
  104. 112. OUR ENGRISH AR TEH MUCH BETTR THAN THEIR JAPANEEZ 渡した血の絵以後の方がまだ増しですから
  105. 113. Descriptive title タイトルだけはわかりやすく
  106. 114. Make it clear what is broken どこが壊れてるかを明記してください
  107. 115. Which function? Which test? With what error? どの関数、どのテストがおかしくて、 どんなエラーが出る、等々
  108. 116. Better if you can provide concise description of the issue 本文でもう少し詳しく説明できるといいですね
  109. 117. What happened when you did what and how いつ何をどんな風にやったら、こうなった、と
  110. 118. translate.google.com and such may help you オンラインの翻訳ツールとか使うのもアリ
  111. 119. Remember you have the last resort いよいよ困ったら英語は忘れてください
  112. 120. Perl
  113. 121. This is our first common language これこそが私たちの共通語です
  114. 122. That's why you should write a test and/or a patch だからこそテストやパッチを書きましょう、と
  115. 123. Part IV Choosing destination 送り先を選ぶ
  116. 124. Now you have all the necessary information to report これで必要な情報はあらかた揃ったはずです
  117. 125. To where should you file the report? さて、どこへレポートしましょうか?
  118. 126. RT? RT ?
  119. 127. Not ReTweet ReTweet の略じゃありませんよ
  120. 129. CPAN's default Request Tracker CPAN 標準のバグトラッカーです
  121. 130. by Best Practical Solutions みなさんご存じですよね
  122. 131. What you see is a bit older version (3.6 HEAD) CPAN で利用されているのはちょっと古い
  123. 132. Latest 4.0 is based on Jifty 最新版は Jifty ベースになります
  124. 133. Ask Jesse when it's out :) いつリリースされるかは社長におたずねください
  125. 134. Also check Lorzy talk by clkao clkao の Lorzy 話も ( たぶん ) RT 4.0 がらみ
  126. 135. Anyway それはさておき
  127. 136. Not everyone uses RT 誰もが RT を使っているわけではありません
  128. 137. google code sourceforge github trac ほかのトラッカーを使っている人も結構います
  129. 138. Read the pod たいてい POD に書いてありますが
  130. 139. META.yml may tell you sometimes META.yml に明記されていることも
  131. 141. OK, now you know where to file どこを見ればいいかわかったら
  132. 142. Make sure to see if similar bugs have been reported or not 似たようなバグが登録されていないか確認
  133. 143. Avoid spamming 同じようなレポートがたくさん届くのは迷惑
  134. 144. See also where is their repository リポジトリの位置も確認しておいてください
  135. 145. search.cpan.org may also tell you sometimes これも CPAN 検索サイトに明記されているかも
  136. 147. External trackers usually tightly-knit with their repository 外部のトラッカーはたいていリポジトリ連動
  137. 148. Commit logs may be found while googling ググるとコミットログが出てくる場合も
  138. 149. Why do we need to find a repository? なんでリポジトリを探すのか?
  139. 150. Your bug may have been fixed in the repository リポジトリでは直っている場合も少なくないから
  140. 151. Not always in the trunk though 場合によっては修正用のブランチも見つかる
  141. 152. Mailing list may also help メーリングリストも要チェックですね
  142. 153. Searchable archives will be your friend アーカイブ検索できるところを覚えておくと便利
  143. 154. Anyway ともかく
  144. 155. Time to file it at last 実際にバグレポートを出してみましょう
  145. 156. Part V RT 101 RT の使い方
  146. 157. The easiest way is to send an email to 一番簡単なのはメールで登録するやり方
  147. 158. bug-<distribution-name> @rt.cpan.org ディストリビューション名は適宜埋めてください
  148. 159. Attach your test and patch テストやパッチは添付ファイルで
  149. 160. If you want finer control もう少し細かい指定をしたい場合は
  150. 161. Try web interface Web インタフェースを使うのもアリです
  151. 164. You need to identify yourself to login スパム対策で身元を確認できるものが必要
  152. 165. Bitcard PAUSE OpenID
  153. 166. Report a new bug 新しいバグを報告する、という項目から
  154. 168. Severity 重要度
  155. 169. Mark as Wishlist if it's not about a bug 要望の場合は自分でチェックした方がいいかも
  156. 170. Broken in, Fixed in バグっているバージョンと直っているバージョン
  157. 171. You usually don't need to care ふつうは気にする必要ありません
  158. 172. May help for a long-standing bug 調べておいてもらえると作者としては楽
  159. 173. Everything is OK? 本文やタイトル、添付ファイルの 準備ができたら
  160. 174. Create 送信
  161. 175. Notification will be sent to all the (co-)maintainers 登録するとすべてのメンテナに通知が行きます
  162. 176. When you receive a reply or a question 返信があったらメールが届きます
  163. 177. Reply to the notification さらに返信する場合はメーラから返信すれば OK
  164. 178. Or login to reply もちろんログインしてから返信してもいいです
  165. 179. When the bug is resolved 解決したバグについてはここに並びます
  166. 181. or unfortunately rejected 残念ながら拒否されたレポートはこちら
  167. 183. Spams will be deleted スパムは単に削除されます
  168. 184. Don't file a comprehensive report to fix multiple bugs 複数のバグをいっぺんに直すような パッチは送らないこと
  169. 185. We can't resolve your ticket by half チケットを半分だけ閉じるとかできませんし
  170. 186. Not all of your patch may be applicable パッチをすべて適用できるとも限りません
  171. 187. Severity varies 優先順位も違ったりします
  172. 188. May be turned down just because it's mixed 複数のレポートが混じっているというだけで拒否られることも
  173. 189. Split your report, patch, test, and whatever パッチやテストはなるべく意味のある まとまりごとにわけてください
  174. 190. One bug, one report バグひとつに対してレポートひとつが原則
  175. 191. with one or more tests テストが複数にわかれるのはかまいません
  176. 192. That isn't considered spamming 適切に分割されたレポートが続くのは スパムとはみなされません
  177. 193. Well, usually ふつうは、ですけどね
  178. 194. Part VI If you're in a hurry 急ぎの場合は
  179. 195. It's nice to report to a tracker 全体のことを思えばバグトラッカーに 報告するのが一番です
  180. 196. Everyone can track it down later 誰もがあとから追跡できますし
  181. 197. Everyone can know what, why and how 誰もが問題と解決策を把握できます
  182. 198. However ただし
  183. 199. It's not the fastest way これは最速の解決策ではありません
  184. 200. If you're in a hurry もし本当に急いでいるなら
  185. 201. or want to make sure あるいは確実に直しを入れてもらいたいなら
  186. 202. Ask the author in person 作者に直接連絡をとりましょう
  187. 203. via IRC IRC 経由でもいいですし
  188. 204. via email 本人宛のメールでもかまいません
  189. 205. Events like YAPC may help このようなイベントで話しかけるのも手ですね
  190. 206. It certainly has downsides このやり方には欠点もあります
  191. 207. No tracker バグトラッカーには記録されません
  192. 208. unless you file it later あとから記録として登録しない限りは、ですが
  193. 209. There may be few (or none) who can help you まわりに助けてくれる人がいない 可能性もあります
  194. 210. IRC has its own local rules IRC には独自のルールがあるのも要注意
  195. 211. Don't ask to ask 「質問していいですか」なんて聞くな、とか
  196. 212. Use nopaste 長いコードを貼り付けるな、とか
  197. 213. But it usually is the most fruitful way ふつうはこれがもっとも実りが多い
  198. 214. No いや、これも正確ではないですね
  199. 215. This is not the last resort in fact 実は究極の手段が残っています
  200. 216. Be a committer コミッタになってしまうことです
  201. 217. coderepos, pugs, jifty, github, alias...
  202. 218. Forgiveness over permission 許可より寛容
  203. 219. Everyone was a beginner at first 誰もが最初は初心者です
  204. 220. Commits can be reverted 変なコミットは差し戻せますからご心配なく
  205. 221. Better if we have more committers コミッタが増えてくれることの方が大事
  206. 222. Ask for a commit bit コミット権がほしいとお願いするか
  207. 223. Or show something to be committed コミットするに足るものを見せること
  208. 224. Learn local rules ローカルルールを確認したら
  209. 225. Start commmitting コミットを始めましょう
  210. 226. Consult core developers if you make a significant change 大きな変更を入れたいときは要相談
  211. 227. The author is unreachable? どうしても作者がつかまらない?
  212. 228. Just forget abondoned modules そんなモジュールのことは忘れるのが一番
  213. 229. Or find the author in any way どうしてもなんとかしたいなら作者を探しましょう
  214. 230. via POD POD に連絡先が書いてあるかもしれませんし
  215. 231. via default <id>@cpan.org CPAN のデフォルトメールに 投げてみる手もあります
  216. 232. Just google it ググればその人の他の活動にヒットするかも
  217. 233. personal blog twitter other mailing list whatever ブログ書いてたり、ぼそぼそつぶやいていたり
  218. 234. Ask in p5p ほんとに大事なモジュールなら p5p で聞いてみるといい
  219. 235. Wait and see 人事を尽くして天命を待つもよし
  220. 236. Or write your own さっさと自前のモジュールをこさえるもよし
  221. 237. Part VII Conclusion まとめ
  222. 238. Don't be shy 黙っていては始まりません
  223. 239. Your reports will make our world better CPAN をよりよいものにするためには みなさんのレポートが不可欠です
  224. 240. But report it to the right places ただ、レポートは適切な場所にお願いします
  225. 241. Reporting a bug in a blog entry is considered harmful ブログに書いておしまい、というのはよくない
  226. 242. miyagawa さんに嫌われます
  227. 243. If you do, at least update your entries after the bug is fixed ブログに書くなら、せめてバグが直ったら その旨書き足さないと
  228. 244. Otherwise, you'll be a source of FUD FUD のもとになりますからね
  229. 245. Writing another entry doesn't help ほかのエントリ書くだけでは足りません
  230. 246. People find your entry via search engines 検索エンジンから来た人は
  231. 247. Nobody reads more than the page they just googled 問題があったページしか読んでくれません
  232. 248. Ok, that's all 以上
  233. 249. Thank you & Questions? ご静聴ありがとうございました
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×