Practical Bug Reporting

  • 2,193 views
Uploaded on

a talk at YAPC::Asia 2009

a talk at YAPC::Asia 2009

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,193
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
9
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

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