問題報告の解決

GNATS データベースには web にもとづくインターフェースがあり、 データベースの要約ページの図表と検索が使えます。 web インターフェースにはいくつか制約があります:

PR は、機密扱いのものを除き、 すべて netbsd-bugs メーリングリストに送られますので、 参加者はデータベースに追加された各 PR を参照することができます。

GNATS データベースは、ホスト gnats.NetBSD.org 上で動いています。 開発者は全員このホストへのアクセス権があり、 PR を直接操作することができますし、 機密扱いの PR にもアクセスすることができます。 /usr/pkg/bin に edit-pr と query-pr というコマンドがありますので、 $PATH にこのディレクトリーを含めておいてください。

このコマンドには UNIX マニュアルページがありません。 ほとんどの GNU ソフトウェアと同様に、 info コマンドで見られる “info” ページがあります。また、 query-pr を引数なしで実行すると、 使い方の説明が表示されます。

query-pr コマンドは、データベース問い合わせ専用のインターフェースです。 このコマンドには、データベース検索用のオプションがたくさんあります。 対象の PR 番号さえわかれば、以下のようにして検索することができます。

PR を変更する理由としては、主に以下のようなものがあります。

修正が必要と思われる各項目を編集して、ファイルを保存し、 エディターを終了します。すると edit-pr は、 変更した各項目 (ほとんどの場合、 >State: と >Responsible:) について、短い説明を入力する よう要求します。 この説明は行単位で入力し、最後に ^D を入力します。

入力後、この説明は電子メールで PR 提出者、担当開発者と、 <gnats-admin@NetBSD.org> に送られます。また、 edit-pr によって、変更を加えた開発者のユーザー ID、 タイムスタンプ、入力した説明が PR に追記されます。

残念ながら、この説明の入力時に外部エディターを呼び出すことはできません。 入力を間違えた場合は、edit-pr を使って訂正する必要があります。

理想的には、問題報告が辿る過程は、以下のようになります。

PR を取り扱う過程の各段階において、電子メールに適切な subject 行を使って メッセージが <gnats-bugs@NetBSD.org> にも流れるようにし、 フィードバックその他の分析、コメントが確実にPR に追記されるようにしてください。 PR の情報を完全に記録することは、 バグの退治と将来のシステム保守のどちらにも役立ちます。

そうすることが可能な場合は、CVS trunk に commit された各修正を、 NetBSD リリースエンジニアリングによって "-release" 枝に対して pull up してもらうことが重要です。そうすれば、リリース枝を追いかけている人たちは、 NetBSD の次のメジャーリリースを待たずに修正を利用できるようになります。 また、こうすることで、NetBSD の次のリリースでは問題を解消することができます。

NetBSD のコミュニティーは、 非常に賢明で非常に経験豊かなおおぜいの人たちの集まりです。 問題報告の分析中に困ったことがあったら、適切なメーリングリスト で質問してみてください。きっと誰かが助けてくれるでしょう。

問題報告の理想的な処理過程は上述のとおりですが、 これが唯一の処理方法というわけではありません。主要な NetBSD 関係者は、 とても忙しい人ばかりですので、NetBSD プロジェクトに専念することはできません。 このため、未着手の PR のなかにあなたが解決可能なものがあれば、 あなたが処理すると宣言 (edit-pr で担当者をあなたに設定) し、 問題を解決してください。

たとえあなたが問題のコードをハックできなくても、 テストケースやその他の情報を提供することができるのなら、 その旨を GNATS に送って PR に追記してください。 “人手が多ければ仕事は楽になる (Many hands make light work)”のです。

問題報告のなかには、修正方法が明らか (あるいは、 提出者が修正方法もつけてくれている) なほどささいなものもあります。 そのようなものは修正が commit された直後に、 open からいきなり closed にしてください。

何らかの理由で PR の処理を最後までできなくなった場合は、 >Responsible: 項目を、 あなたが担当者となった前の担当者のだれかに戻します。 担当者は PR の面倒を見ている最中であるとみなされるので、 他の人が PR の処理を進められないままにしてはいけません。

あなたが PR の担当者である限り、 PR 処理の督促状が電子メールで毎月届きます。 これを使って、PR を見直したり、 時間が経ったものは適切な状態に変更したりしてください。

PR の状態が feedback になっている間は、PR 提出者にも、 返事を促すため、担当者と同様に督促状が電子メールで毎月届きます。 一般的に、3 か月 (督促状 3 回分) たっても何の返事もない場合は、 提出者がどこかに消えたか、 どうでもよくなったとみなしてほぼ問題ないでしょう。 こうなると、PR を閉じるかどうかは担当者の判断 (この問題はどれほど深刻か? 提出者からの追加情報なしに解決すべきか?) に委ねられることになります。

このほか、GNATS PR データベースには、 より大きな問題の解決待ちとなっている問題を追跡し続けるという使い方もあります。 これを書いている時点で、データベース中で最も古い PR である lib/13 (そう、もちろん 13 なのですよ) では、 NetBSD システムの完全な国際化を求めています。 I18N はシステムの大規模な見直しを必要とする難しい問題であり、 これが理由でこの PR は 7 年たっても open のままなのです。 このことは、私たちがこの問題を永久に解決するつもりがないということではなく、 単にこの問題がデータベースにある他の問題のいくつかのものとは深刻さが違うだけなのです。

実際のところ、このような GNATS PR の使い方は、 長期的なプロジェクト追跡システムとして機能しています。