NetBSD プロジェクトでは、 GNATS 問題報告データベースを使って、 全 NetBSD ユーザーからのバグおよび問題の報告を受け付け、追跡しています。 この仕組みを適切に使えば、 NetBSD ソフトウェアの問題が修正されないままになることを防ぐことができます。 GNATS データベースは、主な提出機構としてインターネット電子メールを使っており、 問題報告 (通常 PR と略されます) を、インターネット電子メールの書式 (メッセージボディー中に、拡張されたヘッダー書式を追加) で保持します。 このデータベースでは、 MH メールシステムや NetNews と同様、 問題報告ごとに一つのファイルを使い、 カテゴリーごとにディレクトリーを分けています。 GNATS データベースには web にもとづくインターフェースがあり、 データベースの要約ページの図表と検索が使えます。 web インターフェースにはいくつか制約があります: web インターフェースは実際のデータベースより数時間遅れています。 これは、セキュリティーを確保するため、データベースのコピーに対して操作を行っているからです。 web インターフェースからは、 confidential (機密扱い) 印のついた PR には一切アクセスできません。 web ブラウザーで表示された PR は、変換されているために カット & ペーストしても、期待どおりの結果にならないことがあります (つまり、空白文字が別の文字になったためにパッチが正しく当てられなかったり、 uuencode されたテキストが正しくデコードできなかったりします) 。 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 番号さえわかれば、以下のようにして検索することができます。 query-pr --full <number> こうすると、指定した PR 全体を、 一切の変換を加えずに標準出力に出力します。 edit-pr <number> このコマンドは、テキストエディター (標準では vi ですが、環境変数 $EDITOR または $VISUAL で別のエディターを設定すれば、それが使われます) を起動し、指定した PR を変更できるようにします。 PR を変更する理由としては、主に以下のようなものがあります。 PR の >State: (状態) 項目を、 問題解決の過程が進むのにあわせて、 他のいずれかの状態に変更します。 この変更は、できるかぎり、 PR の >Responsible: 項目に挙げられている人がするようにします。 PR の >Responsible: (担当者) 項目を、 今後その PR を取り扱う開発者のアカウント名に変更します。 変更後の担当者が、 問題解決に関する PR 提出者との主な窓口になります。 この項目には、gnats.NetBSD.org における /etc/passwd のユーザー名と、 /usr/pkg/share/gnats/gnats-db/gnats-adm/responsible ファイルに書かれた名前のどれでも含めることができます。 すべての PR は、最初に記録された段階で、 その PR が属するカテゴリーに応じたデフォルトの担当者を持ちます (たとえば security カテゴリーの PR なら security-officer です)。 /usr/pkg/share/gnats/gnats-db/gnats-adm/categories ファイルに、各カテゴリーのデフォルトの担当者が載っています。 現在の PR に対する担当開発者の一覧表もあります。 PR の >Category: (カテゴリー) 項目を変更します。 PR 提出者が不適切なカテゴリーを選ぶというのはありがちなことです。 PR のカテゴリーとその説明の一覧と、現在のカテゴリー別の PR の表があります。 /usr/pkg/share/gnats/gnats-db/gnats-adm/categories ファイルに、 正しいカテゴリーと、各カテゴリーのデフォルトの担当者の一覧が載っています。 ふつうは、これと同時に >Responsible: も適切な人に変更することが必要です。この担当者はたいていの場合、 変更後のカテゴリーのデフォルトの担当者にするのが適切です。 その他の PR 項目を、 担当開発者の分析結果に応じて変更します。 修正が必要と思われる各項目を編集して、ファイルを保存し、 エディターを終了します。すると edit-pr は、 変更した各項目 (ほとんどの場合、 >State: と >Responsible:) について、短い説明を入力する よう要求します。 この説明は行単位で入力し、最後に ^D を入力します。 入力後、この説明は電子メールで PR 提出者、担当開発者と、 gnats-admin@NetBSD.org に送られます。また、 edit-pr によって、変更を加えた開発者のユーザー ID、 タイムスタンプ、入力した説明が PR に追記されます。 残念ながら、この説明の入力時に外部エディターを呼び出すことはできません。 入力を間違えた場合は、edit-pr を使って訂正する必要があります。 理想的には、問題報告が辿る過程は、以下のようになります。 NetBSD の利用者が NetBSD の問題に遭遇します。 利用者は自分のシステムの send-pr コマンドを呼び出し (そうできる程度にシステムが安定していればの話ですが)、 問題報告を送ります。うまくいけば、報告者は「問題報告の書き方」 のすべての指示に従ってくれます。 システムが send-pr を使えるほど安定していない場合は、 web インターフェース を使って問題報告を提出することができます。 問題報告が gnats.NetBSD.org に届くと、 GNATS データベースシステムがその報告を検査して、分類します。 問題報告の形式に不備がある場合は、機密扱いとなり、 pending カテゴリーに分類され、 GNATS データベース管理者による調停待ちとなります。 形式に問題がなければ、問題報告に PR 番号が振られ、 指定されたカテゴリーに分類され、そのカテゴリーのデフォルトの担当者および netbsd-bugs メーリングリスト宛に電子メールが送られます。 また、 PR 番号とデフォルトの対応担当者についてのお知らせが、 PR 提出者に返信されます。 担当者は PR を読んで分析します。 担当者以外でその問題に対する洞察力を持っている人みんなが、問題報告に追加できる情報を 追加するようにします (報告がメーリングリストにも流れる理由はここにあります。 大勢に見てもらうことで、 問題解決に必要となる重要な知見が得られる可能性が高まります)。 デフォルトの担当者が、別の開発者を担当者にしたほうがよいと判断した場合は、 edit-pr を使って、その PR の担当者を割り当て直すようにします。 新たに担当者となった開発者は PR を読んで分析します。 原因と修正の見込みを見極めたら、 PR に説明を追加し、状態を analyzed に変更します。 この時から、問題修正の遂行が始まります。 過程中のこの部分は、できるだけ早くはじめるべきです。 この問題に遭遇したユーザーは困っていますが、 早い段階ならばユーザーはこの問題に関心を持っていますし、 彼のハードウェアが修正の可能性のテスト用に使えるからです。 PR の鮮度が落ちると、 問題の再現や、修正の可能性のテストができなくなってしまうかもしれません。 修正の実装が完了し、PR 提出者に連絡したら、 PR の状態を feedback に変更し、 本当に問題が修正されたという PR 提出者からの返事を待ちます。 このほか、PR の分析のために、PR 提出者からの情報が必要な場合 (つまり、提出者に質問をした場合) や、 その他の情報源からの情報が必要な場合にも、PR を feedback 状態にします (本質的には、feedback とは待っている状態です)。 問題が修正されたことが確認できたら、 適切な枝へ pullup する必要があります。 pullup 要求を送ったら、PR の 状態 を pending-pullups に変更し、その理由として pullup 番号を列挙しておきます。 PR 提出者が、問題が修正されたことを確認したら、 PR を closed にすることができます。 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 の使い方は、 長期的なプロジェクト追跡システムとして機能しています。 理想世界においては、GNATS PR データベースは空であり、 私たちは完璧なソフトウェアをリリースしており、Microsoft はこの世界の同社そのままでしょう。 PR の >Priority: (優先順位) 項目はこの理想を反映しています。 つまり、優先順位 high はすぐに修正されると考えられています。 優先順位 medium は NetBSD の次のリリース (メジャーまたはマイナー?) までに解決されると考えられており、優先順位 low は そのうち解決します。 基本的に、PR の解決は、提出者の関心、開発者の関心、問題の再現性、 ハードウェアの可用性と、タイミングのよさがほどよく混ざったものに依存しています。 このなかの必要な要素がひとつでも足りなければ、PR は放置されるでしょう。 仮に私たちが PR について本当に傾倒していたら、 問題の実際の重要度や修正できる可能性に応じて、 各 PR の優先順位を定義どおりに調節していたでしょう。残念ながら、 そうするためには、リリースエンジニアリングの目標と目的、 そして全 PR の相互関係を、総体的に評価する必要があり、 分散している集まりにとって、これを組織的におこなうのは難しいことです。 これとは対照的に、>Severity: (重要度) 項目は、 実際に、ユーザーが問題を報告するに際してどれほど困っているかを表現したものです。 なので、これは私たちが慎重に検討することなく調節したりしてはいけないものです。 適切なやり方は、各リリースの時点で、データベース中の全 PR を見直し、 PR ごとに今修正する後で修正する保留するのどれにするかを判断して、 優先順位を調節することでしょう。 いつの日か、そうできるだけの資源と人手が確保できればよいのですが。 リモートホストへのログインが面倒という向きには、 以下の csh のエイリアスが役に立つことでしょう。 alias query-pr 'ssh gnats.NetBSD.org query-pr --full \!* | tee pr-\!*' alias edit-pr ssh -t gnats.NetBSD.org edit-pr