Ruby バグレポートガイドライン¶
English version is HowToReport.
簡単な手順¶
security issue (脆弱性等) を報告する場合は非公開ML security@ruby-lang.org にメールを送ること
- 最新版で試してみる。
- もしあなたがruby 1.9.2-p0 など古いリリースを使っている場合、ruby 1.9.2 の最新パッチリリースを入れて試してみる。 2011-05-09時点ではruby1.9.2-p180が最新です。
- バグフィクスなどをしたメンテナンスリリースなどを使えば仕様変更の心配はありません。
- 以下を準備する。
- 再現手順 (特に再現コード)
- ruby -v の結果
- 実際に起きた結果
- 実行時のログ。
- OSXの場合、プログラムがクラッシュしたときに~/Library/Logs/CrashReporterもしくは/Library/Logs/CrashReporterにログが出力されるので、可能であれば用意する。
- ただしRuby自体がクラッシュしていない場合などには存在しません。[BUG]などと書かれてRubyが終了した場合はRuby自体がクラッシュしています。
- 期待した結果
- 例) この例外は起きないべきだ
- 例) ここでこの例外が起きるべきだ
- 以下のページを開き、New Issues をクリックする。
- 1.9 で再現するバグを報告する場合: [[Ruby 1.9:]]
- 1.8 と 1.9 の両方で再現する場合: [[Ruby 1.9:]] に登録し、1.8 でも再現した旨を記す。
- 1.8 で再現するバグを報告する場合: Ruby 1.8
- フォームを埋めて登録する。
- Tracker: 通常は "Bug" report か "Feature" request を選ぶ。
- field_mailing_list: 英語 or 日本語を選ぶ。
- Subject: 問題を最大 60 文字程度で書く。
- Description: (1) で準備したものを簡潔に書く。自然言語は 140 字に収まる程度だとよい。
- Status と Priority はそのまま。
- ruby -v: ruby -v の結果をそのまま貼りつける。
- 他は適当に。よくわからなければそのままでも構いません。
- 気長に見守る。
- 10 日程度反応がなければ、見過ごされている可能性が高いので催促しても構いません。
- feedback を求められたら答えてください。feedback に状態が変更されて数ヶ月たつとrejectされる場合が多いです。
- reject されても泣かない。
より確実な・間違いがなさめなバグ報告をしたい方は下記もご覧下さい。
よりよい報告の手順¶
- 軽く下調べする
- 似た報告がないか簡単に検索する (Google 程度で OK)
- 可能なら trunk とそのバージョンのメンテナンスブランチなどで再現するか調べる
- すでに報告され、直っている場合があります。
- 以下を準備する
- 再現手順 (特に小さな再現コード)
- なるべく短くて外部ライブラリを使わないコードだとよい
- 再現コードで gem を使っている場合は、再現手順に gem install foo などと書いてください。
- ログだけ、xxというソフトウェアでyyをしたときに...だけなど、開発者は確実に再現できるコードを提示しないと動かない事が多いです。
- ruby -v の結果
- 実際に起きた結果
- 実行ログを全部貼り付ける。むやみに省略しない。
- 実行ログ。OSXの場合は~/Library/Logs/CrashReporterもしくは/Library/Logs/CrashReporterに出力されるクラッシュログがある場合は、それも用意すると良い。
- 期待した結果と、それを期待した理由
- 理由の例: rdoc に書いてある、旧バージョンでは期待通りに動いた、他の挙動から類推した、etc.
- この問題の重要さ
- 例: 影響を受けるライブラリ名を挙げる、影響を受けるユースケースを示す、回避策がない、etc.
- 使用したコンパイラとそのバージョン
- デバッガのバックトレース (異常終了する場合)
- gem list や gem env の結果 (gem を使用している場合)
- 自分でソースからビルドした場合は、configure に与えたオプション
- その他、独自の考察やパッチがあればそれも
- 再現手順 (特に小さな再現コード)
- フォームを開いて埋める。(「簡単な手順」を参照)
- 気長に見守る。
- reject の理由に納得がいかなかったら、反論するといいです。ただし reject の理由をきちんと理解した上で。
- 良い例) 「軽微な問題なので対応しない」という reject に対して「問題の重大さ」を説く
- 悪い例) 「メンテナ不在のため対応不能」という reject に対して「問題の重大さ」を説く
- 悪い例) 「仕様の変更」という reject に対して「問題の重大さ」を説く
- 「バグではない」と言われた場合は、仕様変更にならない形で Feature request として再登録することを検討する
- 「互換性維持のために修正不能」と言われた場合は、Ruby 2.0 の仕様策定の機会を伺う
- 「メンテナ不在のため対応不能」と言われた場合は、自分でパッチを書くか、書いてくれる人を探す・雇う
- feedbackのまま長期間返事がないとrejectされることが多いです。定期的に確認すると良いでしょう
- ruby-dev, ruby-coreの購読や、redmineのwatch機能を使うと気づきやすいです。
- reject の理由に納得がいかなかったら、反論するといいです。ただし reject の理由をきちんと理解した上で。
- 「修正した」と言われたら、修正されていることを確認する。
- preview リリースや RC リリースが出たら、再度確認する
よりよい報告のための tips¶
Ruby 特有の話
- trunk の取得方法: レポジトリガイドを参照。svn
が使えないならスナップショットを使うと良い。
- gdb でのバックトレースの取り方: gdb --args ruby foo.rb で起動し、run
で実行し、落ちたら bt を実行する。
- rvm を使わずにテストする (rvm 側の問題と切り分けるため)
- ユニットテストを書けると良い (必須ではない。test/ 以下を参考に)
- パッチを書いた場合は make update-rubyspec ; make test-rubyspec ; make check を確認する (詳しくは DeveloperHowtoJa を参照) 。
バグ報告一般の話
- 本当にバグか今一度考える
- 「自分の直感に合わない」という主観は大切ですが、客観的な事実も書いた方が通じやすい
- rdoc やるりまを参照して、仕様を確認する
- バグかどうかの自信が持てない場合は、登録前に ML や IRC で聞いてみるとよい
- IRCとMLのリスト を参考に参加してみる
- 過去に報告済みでないか、検索等で簡単に調べる
- 1 つのバグ報告では 1 つのバグだけを報告する
- 必要十分な情報を簡潔に書く
- 再試するための情報がすべて載っていることを確認する
参考: よくある誤った/すでに解決済みのバグ報告¶
小数計算の結果がおかしい
浮動小数点数の計算には誤差があります。参考サイト: * http://download.oracle.com/docs/cd/E19957-01/806-4847/ncg_goldberg.html * http://wiki.github.com/rdp/ruby_tutorials_core/ruby-talk-faq#floats_imprecise * http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems
- String#gsub で \ (円マーク・バックスラッシュ) に置換しようとしたら何かおかしい
- 仕様です。String#gsub を参照。
- lib/ruby/1.9.1/net/http.rb と "CFUNC :connect" の文字がログにあって OS X を使っている
- openssl を自分でインストールしてそれを利用するように ruby をビルドし直すと治る事があります。 (homebrew なら brew install openssl 等)
- その後 configure に --with-openssl-dir=/usr/local 等と openssl をインストールした prefix を指定、また rm ext/openssl/Makefile した後にもう一度 make すると良いです。
注意事項¶
- このガイドラインは、バグ報告者と開発者のコミュニケーションを円滑にし、バグ報告と修正を効率的かつ円満に進めるためのものです。
- バグ報告者はこれに従う義務はありませんが、なるべく従うことを推奨します。特に「簡単な手順」の 1 は、バグ修正のために事実上必須です。
- バグ報告がこのガイドラインに従っていないというだけで reject されることはありません。ただし、情報が足りないバグ報告に対して、このガイドラインを指示・引用して feedback をお願いすることはあります。
- このガイドラインが常に適切とは限りません。適切でないと思う場合は更新してください。(更新する前に ruby-dev (日本語) か ruby-core (英語) で議論するとよいです)