
490
27
章 自力でのエビデンスマイニング
それぞれにマッチしたものが、バグへのリンクの可能性があります。しかしこのやり方では、多くの
擬陽性の(間違った正の)判定をする可能性があります(たとえば、「
Updated copyrights to 2004
」な
ど)。リンクを検証するためには、リンク先のバグレポートにある情報も吟味しなければなりません。
修正を行っている変更にだけ興味があるわけなので、以下の特徴をすべて持つバグ報告へのリンクだけ
に絞ることができます。
●
状態フィールドが「
closed
(完了)」である
●
解決フィールドが「
fixed
(修正済み)」である
●
解決日付が調べているコミットメッセージのコミット日付に近いもの(たとえば違いが
5
日以内)
リンクの検証のためにさらなる基準をチェックすることもできますが、その基準はソフトウェアプロ
ジェクトの開発プロセスに依存したものになるのが普通なので、各プロジェクトごとに調整する必要が
あります
。また、同一のトランザクションで適用しているコード変更が、
1
つ以上のバグを修正してい
る可能性があるということにも留意してください。
バグレポートをコード変更にリンクする(オプション)
多くのプロジェクトでは、参照の候補を見つけるためにコミットメッセージをスキャンするだけで十
分ですが、別の
/
追加のステップを必要とするプロジェクトもあります。たとえば
Cubranic
と
Murphy
は、逆方向つまり
Bugzilla
から
CVS
アーカイブへのリンクを、バグに関する活動と変更とを ...