a talk at YAPC::Asia 2009

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 テスターのみなさん

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 万件越えてます

17. 166 Testers 先月レポートを送ってくださった方は 166 人

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 いつかはバグに当たることでしょう

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 向けのフィードもあります

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

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 の略じゃありませんよ

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 に明記されていることも

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 検索サイトに明記されているかも

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 インタフェースを使うのもアリです

164. You need to identify yourself to login スパム対策で身元を確認できるものが必要

165. Bitcard PAUSE OpenID

166. Report a new bug 新しいバグを報告する、という項目から

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 解決したバグについてはここに並びます

181. or unfortunately rejected 残念ながら拒否されたレポートはこちら

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