Ottawa Linux Symposium 4日目リポート（4/5 ページ）

[David-'cdlu'-Graham，japan.linux.com]

　次いで、話題をバグ報告と管理に移し、Red Hatがバグの追跡に使っているBugzillaを中心に長い時間をかけて語った。ジョーンズ氏は、Bugzillaはバグ追跡のすべてではないが、同社の中では最善のものだと言う。

　ある日のこと、カーネル・コードを見るのに疲れたジョーンズ氏は、GNOMEソース・ツリー全体をgrepして、ありがちなバグを探してみた。すると、50ほども出てきた。そのすべてについてパッチを書いたのだが、その報告については考え込んでしまった。GNOMEのバグを見つけた場合、そのバグをパッチとともにbugzillaに登録することになっているが、それには長い時間がかかる。結局、誰かがジョーンズ氏の代わりに処理してくれたのだった。

　ジョーンズ氏は、バグを報告する者の心理を理解することが重要だと指摘する。誰でも、自分が発見したバグが報告されたバグの中で最も重要なものだと考える。誰かが重要な問題を引き起こすバグに気がつき、別の人が他の重要な問題を引き起こすバグに気づいたとき、当事者にとってはどちらも重要な問題だが、バグを抱えているソフトウェアから見れば、いずれかのバグを優先しなければならない。だから、バグ・システムでユーザーが指定する優先度は役に立たない。誰もが自分の発見したバグに最高の優先度を与え、本来の目的を無視するからだ。ジョーンズ氏は、ほとんどのバグ・システムでは優先度は単に無視されるだけだと言う。

　中には、バグを報告する際に細工をする者もいる。出力を編集して、カーネルが汚染されていることを警告するカーネル・モジュールのローディング・メッセージを隠してしまうのだ。この情報がなければ、バグの解決などおぼつかない。

　バグを見つけたユーザーの多くは開発過程の上流に報告しようとせず、カーネルではなくディストリビューションに責任を求める。別のディストリビューションに乗り換えてバグを回避するユーザーもいるが、ほどなく、カーネルをアップグレードしたときに同じバグに遭遇することになる。

　ヒット・エンド・ランを行う者もいる。バグを報告しても、そのバグを解決するための質問には回答しないのだ。やむなくバグは情報不足でクローズされるが、クローズされると、当のユーザーは再度オープンさせ、解決されていないのにクローズしたと腹を立てる。しかし、バグを解決するための情報収集には協力しないのである。

　バグを報告する際、何の関係もない情報を長々と添付してくる者もいる。ときには、コンピュータを買った店や値段まで書き添えてくる。無用なログ出力を何千行も添付するのに、肝心の問題については役立たずの短い説明しかしない人もいるのだ。

　中でも厄介なのは、カーネルの古いバージョンが持つバグを報告し、アップグレードしようとしない者である。

　こうした気むずかしいバグ報告者は「のらくら者」だと、ジョーンズ氏は言う。こうした人たちはバグを見つけると、あちこちいじり回すが、その結果は芳しくない。そのうちバグを改修した新バージョンがリリースされるが、それでも問題は解決しない。あちこちいじり回したツケが回ったのだ。そして、どれかのアップグレードで、たまたま、動き出したりする。

　ジョーンズ氏が思い描くBugzillaの将来バージョンは、相互に情報を交換する機能を持っている。あちこちにいろいろなBugzillaがあり、必要に応じて、バグを上流へあるいは下流へと回送するのだ。

　なぜなら、多くのバグはディストリビュータに報告されるが、本来対応すべきカーネル・チームにまで届くことはなく、一方、何か所かに同時に報告されるバグもあるからだ。

　Bugzillaと、Red Hatによるその実装の話を終える前に、ジョーンズ氏は全体的な傾向について語った。

　バイナリのみのカーネル・モジュールの使用はかなり少なくなり、週に数件あったバグの報告が、月に数件だけになった。しかし、バイナリのみのヘルパー――Linuxの下でWindowsドライバを使ってハードウェアを動かすためのドライバ・ラッパー――の使用は増えている。

　ジョーンズ氏は、バージョン2.0.30のカーネルに初めて参加したとき以来、時代は変わったと述懐する。カーネルは以前より遥かに複雑になり、学ぶのが難しくなった。かつてはカーネル開発に追いつくのは容易だったが、今ではコツを学びカーネルに馴れるには長い時間がかかるようになったという。

　ジョーンズ氏はvalgrindやgcc -DFORTIFY_SOURCEなどを利用してカーネルのバグを発見し除去する方法について述べた後、満員のフロアとの質疑応答に入った。

　その中に、SETI@Homeのように、分散コンピューティング・モデルがバグの発見と解決に使えるだろうかという質問があった。ジョーンズ氏は、実用的なソリューションにはならないだろうと答えた。バグを見つけたとしても、そのときはホスト・システムが動かなくなっているだろうから、調整用のサーバにバグを報告できないのだ。

　デイブ・ジョーンズ氏に会ったら、サルと宇宙船について尋ねてみよう。

　基調講演の後、OLSの組織委員会から種々の発表があり、協賛団体にはその変わらぬサポートに対して、参加者には今年の催しが無事終了したことに対して謝意を表明した。

　最後に、精力的なGreg Kroah-Hartman氏を来年の基調講演者に指名して幕となった。