top  Index  Search  Changes  RSS  Login

バグレポートFAQ

このページについて

このページは何ですか?

このページは, バグレポートに関するよくある質問(および文句)に 対する回答です.

…というふりをして, 「適切なバグレポート」についてのお願いを 書いています. howm に関する不具合や改良案をお知らせいただく前に, ご一読ください.

このページを要約してくれませんか?

何かが思いどおりにいかないとき, 考えられる原因の候補は 数えきれないほどありえます. そこから真の原因をみつけださないと問題は解決しません. 「デバッグ」は可能性との格闘です.

可能性を絞り込むためにまずやるべきなのは, 原因を「推理する」ことでも, コードを「読み直す」ことでもありません. 起きている現象を「観察」して, どこからおかしくなっているかつきとめることです.

このような調査は, 作者自身がやるのが一番効率的です. ユーザーにお願いしたいのは, 「作者がこの作業をできるようにすること」. 具体的には, 「作者の手元でバグを再現させること」です.

そのためには, 再現できるよう十分な情報を提供いただくことが鍵となります. 情報があいまいだと, 可能性が倍増し, 最初に述べた格闘で大きなハンデを負って しまいます.

とはいえ, 「十分な情報」を挙げるのは, 意外と難しいしめんどうなものです. そこで, 「適切なバグレポート」が簡単に書ける仕組み(make test) を用意しました. ぜひご活用ください.

…以上が, このページで言いたいことです.

レポート方法について

バグっぽいんだけど?

make test (Windowsなら test.bat) を実行して, BugReportPaste2ch-current:l50 へ貼ってください.

バグじゃなくて要望なんだけど?

make test で表示される最初の質問 「何をしたら, どうなってほしいのに, どうなった?」 への答を, アイデアか 2ch に貼ってください.

いや, だからバグじゃなくて要望だって言ってるんだけど?

要望を実現するには, コーディング以前に, 要望の内容を 作者が理解する必要があります. また, 内容だけでは不十分で, 意図(なぜそれが欲しいのか) も伺っておきたいところです. あなたが howm のプログラムを知りつくしているのでない限り, あなたの案とは別の簡単な解決策があるかもしれないからです. (それに, 何の役に立つのかわからないままでは, やる気が出ない …という本音もあります.)

ところが, 要望をいただいても, 内容や意図がわからなくて困ることが 結構あります. そもそも, あなたの頭の中にある考えを文章だけで正確に伝えるのは, 実はかなり難しいものです. (加えて, 作者の理解力の問題もあります.)

「じゃあ伝えられるように文章術をみがく」というのも結構ですが, それよりも make test の質問に答えていただく方が, 手軽だし確実でしょう. できるだけ具体例で説明するのが, わからせるコツです.

test.bat をダブルクリックしてもうまくいかないのですが?

test.bat をエディタで開いて, 「set HOWM_EMACS=」の行を環境にあわせて 書き直してください. (emacs/meadow のフルパスを書く)

※ ここを自動化できる方法があったら教えてください.

ちょっと自信ないから, 自分の blog に書いとくのじゃだめ?

ここも 2ch も匿名なんだから, もし仮にあなたのミスや勘違いでも, 恥はかき捨て. 早く確実に作者へ伝わるぶん, 得じゃないですか.

作者に手間やプレッシャーをかけるのは心外なので, 自分の blog に書いとくのじゃだめ?

お気づかいありがとうございます. でも, 「適切なバグレポート」なら, 別に負担ではありません.

「ガイシュツ上等」って本気?

本気です. 「適切なバグレポート」なら, 既出なことは作者にはすぐわかりますから, 負担になりません. 適切でないバグレポートに対応するのと比べたらぜんぜん手軽です.

どういうのが「適切なバグレポート」なんですか?

make test です.

make test について

make test をしないとどうなる?

作者から「make test をお願いします」というレスがつきます. この往復のために数日が無駄に過ぎるでしょう.

make test すると何が起きるの? プライバシー情報を勝手に送信されたりしない?

通信は一切しません. MakeTestSampleのような質問票が表示されるだけのことです.

なぜそんなに make test にこだわるの?

良いバグレポートをゼロから書くのは, 意外と難しいからです. どんなレポートが良いのかなんてふつう教わりませんし, 「そんなの重々承知」な人でもうっかり何か抜かしてしまうことが多々あります (作者自身そうです).

質問票とかめんどうそうなんですが?

質問は厳選した 3 問だけです. それ以外の知りたい情報(バージョン一式)は自動で表示されますから, そのまま貼るだけ.

それでもめんどうそうなんですが?

「意図どおりに動作しない原因」の候補は, 数えきれないほどあり得ます. そこからなんとか可能性を絞って原因を特定しないとバグは直せません.

そのとき, レポートにあいまいな点があると, 可能性を絞れなく なってしまいます. あいまいな点が一つあるたびに, 調べることが倍になります (A なら…, B なら…). 三つあれば, 2×2×2 = 8 倍です. ただでさえ山のような可能性と格闘するのに, さらに可能性を広げて 難度を上げられては…

そういうあいまいさを避けるための質問票ですから, ご協力ください.

一介のユーザー(しかも初心者)である私が協力しないといけないんですか?

あなたのマシンで起きたことを伝えられるのは, あなただけです.

あなたはあなたのマシンを簡単に観察できます. 一方, あなたのマシンに何が表示されているのか掲示板ごしに「推測」するのは 至難の技です.

あなたにとっては簡単なことで, 作者にはとてつもなく難しいことですから, そこだけはご協力ください.

レポート内容について

バックトレースを送らなくていいんですか?

make test でちゃんと答えてもらえば, 作者の手元で再現できる可能性が高まります. 再現できればバックトレースなんて自分でとれるし, もっといろいろ存分に調べられます.

ですから, 作者の手元で再現させることをまず目指してください. バックトレースは, それがどうしてもできないときの次善策です.

なぜバージョンをいちいち書かなきゃいけないの?

バージョンによって対処法が違う場合があるからです. また, 前に述べたように, 余計な可能性を広げたくないのも 強い理由です.

make test で表示されたバージョン一式を貼ってもらえば, どちらも簡単に避けられます.

なぜ「バージョンは最新版です」と書くのはまずいの?

「最新版」だけではリリース版かテスト版か判断できません. さらに, たとえ「最新リリース版」と書かれていても, 後から読んだときにどれのことなのか調べるのがめんどうです.

…本音を言うと, 「この人が最新だと思っている版は本当に最新版 だろうか」という余計な心配が増えるのが, 一番困る点です. あなた自身はしっかり者かもしれませんが, 世の中にはうっかり者(例えば作者)もいて, 掲示板ごしではすぐにはどちらか見分けられません. 可能性が増えると負担が倍増することは前に述べました.

そもそも, バージョンを手書きするのが失敗の元です. make test で表示された一式をそのまま貼りつければ, 書き漏らしもなくなるし, 上のような文句もなくなるし, 一個一個しらべる手間も省けます.

なぜ「考えられる原因を教えてください」と書くのは要注意なの?

このセリフ自体には, 害も益もありません. が, これが書いてあるレポートは, えてして情報不足なことが多いようです. 「原因を断定できるほどの情報を提供していない」という自覚から このセリフが出ているのだとしたら, 考え直してください.

情報が不十分だと, 原因の候補なんて数えつくせないほどありえます. その中からいくつか挙げてみて当たることを願う…なんて, 効率が悪すぎます. 「デバッグ」は, そんなふうにするものではありません.

デバッグの第一の原則は, 「推理すること」でも「コードを読み直すこと」でも ありません. 「起きている事実を観察し, どこからおかしくなっているかつきとめること」です. これができるかどうかは, 必要な情報が提供されているかにかかっています.

質問票について

最初の質問「何をしたら, どうなってほしいのに, どうなった?」の意図は?

とにかくまず知らせてほしいのは, どんな操作をしたのかです. それも, 具体的なキー操作を書いてください. 「検索した」と書かれただけでは, いくつかある検索方法のどれをしたのか わかりません. また, 「適当な単語を」などと書かれても, 特定の単語でないと 発症しないかもしれません. 何度も言うように, 余計な可能性を広げないようお願いします.

目標は, 作者の手元で発症させることです. 手元で発症すればデバッグは簡単, そうでなければとても難しくなります. 確実に発症させるために, PC 初心者へ手順を教えるつもり (「サルでもわかる○○」レベル)で, 極めて具体的に書いてください.

それから, 「どうなってほしいのに」も忘れないでください. 仕様かバグか, 思い込みか不具合か, を判断する大切な項目です.

意外かもしれませんが, 「どうすれば直せるだろう」という悩み以前に, 「この人は何を困っているんだろう」がはっきりしなくて悩むことがよくあります. オレ用語で長々説明するより, 具体例を一つ書く方が確実です.

最後に, それと現実とどこが違うのかを書いてください. 原因の憶測などはいりません. 解釈を一切加えず, 見た事実そのものだけをありのままに伝えてください.

「検索できません」と言われても, 検索結果に表示されないのか, それともエラーが出るのか, …と可能性がまた広がって困ります.

次の質問「make test や test.bat からその操作をしても, 症状が出る?」の意図は?

ふつうに emacs を起動したのでは, あなたの .emacs しだいな点が多すぎて, 可能性を絞りきれません. make test ならほとんど無設定の emacs が起動しますから, 話がずっとシンプルになります.

最後の質問「出ないなら, sample/dot.emacs に何を追加したら発症する?」の意図は?

make test から発症させる方法をみつけられたら, そのまま作者の手元で再現できる望みが大きくなります. 再現できれば何でも存分に調べられる, というありがたさは既に述べたとおりです.

だいたい, 作者が howm を使い倒しているのにそのバグに気づかないのは, 「設定が違うから」という理由が一番ありがちです. ですから, 発症する設定を伝えていただくのが, 解決への近道です.

その他

なんでおれがこんなめんどうなことさせられるんだ. おまえのバグだろ. おまえがちゃんと調べるべきじゃないか?

ライセンスに「無保証」が明記されています. バグを直す「義務」はありません.

とはいえ, できるだけ直したいと思っています. 思っているのですが, 協力していただけないと直すのが絶望的に 難しくなってしまいます.

howm には大量の設定項目があって, 発症する組合せを作者の方で みつけ出すのはほとんど不可能です. 一方, あなたの方は, 発症させる .emacs を持っているのですから, すでに「発症する組合せ」を手に入れています. それを教えてください.


  • 書いてはみたけど…. くどくど言うより「スクリーンショットとキー入力ログを見せてくれ」の方が早い気もしてきた. → M-x howm-bug-shot (howm-1.3.1 から)
  • 2006-03-21 (火) 09:36:54 逃避 : せっかくの機能なのでご連絡ですが、howm-bug-shot は Symbol's function definition is void: window-list になります。(howm-1.3.1/Meadow-1.15/Win2k)
  • thx. テスト版で対処してみました.
(Please LogIn to post comments.)

Last modified:2008/03/09 14:26:20
Keyword(s):
References:[AttachableTimer] [OrgMode] [HidePrivateReminder] [バグレポート]