8.1. 見つけたバグを報告するには#

バグを報告する方法はいくつかあります。

どのやりかたを使ってもらっても構いません。

8.1.1. Issue trackerにバグを報告する#

Mroongaプロジェクトでは、 GitHub issue tracker を使っています。

バグを報告するのは英語でも日本語でもどちらでも良いです。

Mroongaプロジェクトでは、Mroongaについて話すコミュニティがあります。バグの内容を記載したEメールを送ってください。

Mroongaがクラッシュしたり、SQLの結果が期待通りでない検索結果を返すことがあります。そういった問題を解決するためには再現可能なバグ報告が必要です。

再現可能なバグ報告には、次の情報をできるだけ提供してもらえると、問題を調査するのに役立ちます。

Name	Description
環境情報	どのバージョンを使っているか、インストールしたパッケージの情報 rpm: rpm -qa > INSTALLED.txt deb: dpkg -l > INSTALLED.txt Windowsではどのzipパッケージを使っているかを教えてください。
問題の引き金となる実行中のクエリー	実際に実行したクエリーを示します。
サンプルのスキーマとデータ	問題を再現させる小さなサンプルスキーマとデータを提供してください。問題をすばやく解決するのにつながります。
MySQLのエラーログ	より低レベルのエラー情報を含んでいます。例えば `/var/log/mysqld.log` にあります。( `log-error` 設定によりかわります)
groonga.log	より低レベルのエラー情報を含んでいます。例えば `/var/lib/mysql/groonga.log` にあります。( `mroonga_log_file` の設定によりかわります)

上記の情報がバグの再現に十分でない場合、追加の情報が必要です。

Name	Description
MySQLのダンプ	同じデータベースを再構築するのに必要です。 `mysqldump -u USER -pPASSWORD --opt --flush-logs --single-transaction --master-data=2 --default-character-set=utf8 --hex-blob --databases DATABASE > dump.sql` などとして作成します。
MySQLのbinlog	ダンプデータが問題の再現に十分ならば必要ありません。例えば、 `/var/lib/mysql/mysql-bin.*` にあります。 ( `log-bin` の設定によりかわります)
MySQLのデータディレクトリー(オフラインバックアップ)	ダンプデータやバイナリーログが残っていない場合、必要になることがあります。例えば、 `/var/lib/mysql/` にあります。 ( `datadir` の設定によりかわります)