openSUSE:バグ報告FAQ

移動先: 案内, 検索
この記事では bugzilla.novell.com にある bugzilla の使い方と、 バグ報告時によくある質問について、その一覧と各回答を示しています。

目次

どのような種類のフィードバックを行なうべきか

我々は、肯定的なフィードバックと否定的なフィードバックの両方に加え、改善のためのアイディアを必要としています。

  • 肯定的なフィードバックとは、システムが正しくインストールできてうまく動作した報告のことで、特定の領域についてテストを行ない、問題なく動作したことを表わすものです。このような報告は opensuse-ja@opensuse.org メーリングリスト に送ってください。これらのフィードバックはテスト用のデータベース内に記録します。
  • 否定的なフィードバックとは何らかの問題に直面したという報告で、これらは Bugzilla で管理しています。 何らかの問題に遭遇した場合は、その問題ごとに別々のバグ報告を行なってください。以下では、このバグ報告の際、どのようにしてバグを説明すべきかについて FAQ 形式の説明をしています。
  • 改善のためのアイディアについては、一般にフィーチャーリクエストと呼ばれますが、これらも是非お送りください。これらは openFATE と呼ばれるデータベースで管理しています。
bugzilla.novell.com では標準の言語として英語を利用しています。 バグ報告の際は英語で記入いただきますようお願いいたします。

一般的なバグの処理

どの項目を最初に埋めておくべきか, どの項目を変更すべきか

  • Component (コンポーネント)
    注意: インストール時にバグに遭遇しても、それらの全てが YaST とは限りません。カーネルなどである場合もあります。
  • Platform (プラットフォーム)
    プラットフォームに依存しないと思われる場合は "all" を選択してください。それ以外の場合はお使いのプラットフォームを指定してください。
  • Summary (概要)
    概要欄には、どのような問題であるのかが一目でわかる記述をお願いします。
  • Bug description (バグの説明)
    バグについて、より詳しい説明をお願いします。なお、上記の概要欄については更新される場合があるため、概要欄に関する言及は避けてください。
  • How to Reproduce? (再現手順)
    さらに細かい説明を行なうため、再現手順の記入も重要です。
  • Severity (重要度)
    重要度は正しく選択してください。どうしても回避策がなく、作業を妨害される場合にのみ "blocker" を選択してください。また、 SHIP_STOPPER と呼ばれるフラグも設定可能ですが、これは対象のバグが解決されない限り、製品を公開してはならないとお考えの場合にのみ設定してください。
  • 上記以外
    上記以外の項目は必要に応じて埋めてください。全てを埋める必要はなく、既定値のままでかまいません。

バグ報告後の対応の受け取り方

"preferences" (設定) で受け取らないように設定している場合を除き、何らかの変更があれば随時電子メールにて通知が届きます。

バグに対する質問やコメントなどであれば、それらを直接電子メールで送信することは避け、 bugzilla の Web インターフェイスを利用してください。電子メールは個人的に送信されて公開されることはないので、後から誰かが詳細を知ろうとしてもわからなくなってしまうためです。

どの項目を変更すべきで、どの項目は変更すべきではないか

開発者でない場合、一般的にはコメントを追記したり自分自身を CC に追加したりすることで対応を行なってください。 また、バグが "NEEDINFO" の状態で、求められた情報をすべて記入した場合は、必ず "ASSIGNED" の状態に戻してください。
"NEEDINFO" から "ASSIGNED" に戻す際は、コメント欄の下部にあるチェックボックス ("This comment provides the needed info" (このコメントには、求められた情報が書かれています)) をお使いください。

古いバージョンの openSUSE に存在し解決済みであったバグについて、これと同じ (または似通った) ものが新しいバージョンに発見された場合

バージョン番号を新しいほうのものに修正し、 "This bug was reported for openSUSE x.y and still fails for openSUSE u.v. I'm adjusting the version" (このバグは openSUSE xy で報告されたものですが、 openSUSE u.v でも発生しました。そのためバージョン番号を変更しています) のようにコメントを記述してください。 また、対象のバグが既に閉じられたものであった場合は、バグを再度開いて (reopen) ください。

Bugzilla の "how to reproduce" (再現手順) の欄に、 "openSUSE x.y-Beta-z をインストールする" を記入してはならない理由

これは全く不要な情報であるためです。バグを再現させるのに OS のインストールは必要不可欠で、 わざわざ記述しても意味がありません。また、インストール時のバグについては、バージョンを選択したあと、 Bugzilla のコンポーネント (Component) 一覧から "Installation" を選択してください。

本当に必要な情報とは、何を実施したかという情報と、それをどのように実施したかという情報です。たとえば "CD1 から起動して "インストール" を選択し、 "Klingon" 言語を選択します。インストールの設定はそのままで先に進めると、ハードディスクが動き出します" などです。

これは我々があら探しをしているように感じられるかもしれませんが、そうではありません。 openSUSE には多数のインストールモードや手順が存在していて、ログファイルなどだけでは判断できない場合があるためです。ですから、情報提供にはできる限りご協力いただくことをお願いしています。

もちろん、最後のハードウエア設定ダイアログ (プリンタや TV カードなど) のヘルプテキストに誤りがあるような場合には、上記のような詳細な手順は不要です。ただし、そのテキストが表示される場所についての説明は詳しく記述してください。 openSUSE では多数のダイアログが存在していることから、問題のあるダイアログがどこにあるものか判別できない場合があるためです。

Bugzilla のバグ説明の欄に "see subject" (タイトルのとおり) とだけ書いてはいけない理由

タイトル部分は必要に応じて変更される可能性があります。たとえタイトルですべてを説明しきれるものであったとしても、後から参照した場合に読めなくなってしまうことを避けるため、タイトルとは別にコメント欄に説明を記載してください。

タイトル欄は関連する情報を書いておく場所ではなく、バグ報告における最も重要な情報を端的に記述しておく場所です。

つまり、タイトル欄にすべての種類の情報を書き並べておくのもよくありませんし、タイトル欄を参照するようにコメントを記述するのもよくありません。わざわざコメント欄に記入するのは単なる手間でしかないのは確かですが、バグを検索しているユーザに対して適切な情報を提供するためにご協力をお願いいたします。

また、これらに加えて、タイトルは簡潔であるべきである一方、続くコメント欄で詳しい説明を行なってください。


バグの状態 NEEDINFO について

バグに書かれた NEEDINFO の状態について

NEEDINFO とはバグの所有者 (そのバグに対応している人) が、そのバグに関する追加情報を求めていることを 示しています。通常、追加情報はバグの報告者が提供します。

報告したバグが NEEDINFO の状態になった場合は、最新のコメントに書かれた質問内容や要求内容をお読みの うえ、追加の情報として何が必要なのか (たとえばログファイルなど) をご確認ください。

必要な情報を集めたら、コメント欄でその質問に回答するか、必要な情報を登録してバグの状態を ASSIGNED - click on Accept bug (change status to ASSIGNED) に設定してください。

なお、質問への回答やログの添付については、 Bugzilla の Web インターフェイス経由で実施してください。 特別な事情がない限り、電子メールで情報の提供を行なったりはしないでください。これらの情報はバグに対応する多くの人々にとって必要な情報であるため、修正を素早く行なう目的から、誰にでもアクセスできるようにしてください。

バグの状態を NEEDINFO から ASSIGNED に変更した場合の所有者について

状態が変化しても所有者は変化せず、そのままです。これによって、報告者自身に責任が生じるようなこともありません。

NEEDINFOASSIGNED に戻すことの重要性について

状態の変更は、質問に対する回答や情報提供を行なったユーザ側の責任で実施します。

バグの所有者 (担当者) は NEEDINFO の状態にすることで、報告者側の回答待ちであることを管理します。 その後、状態が ASSIGNED, NEW, REOPENED に変化することを確認することで、 そのバグに対する対応を再開します。

このような理由から、所有者はバグを NEEDINFO の状態に設定します。 情報の提供には、どれだけの時間がかかるのかがわかりませんから、 NEEDINFO の状態にしておくことで、そのフラグが変化する (つまり、メールでの通知が届く) のを待つわけです。

メンテナンス担当者は、特にベータテスト中など、ピーク時に多数のメールを受け取る都合上、個別のバグに対して状況を詳しく確認することができません。そのため、一定期間おきにバグの状態リストを確認して作業を進めています。このタイミングで状態が変化していれば、作業を再開できることになります。

このような仕組みから、必要な情報を提供したあとは、バグの報告者自身が NEEDINFO から状態を変化させる必要があります。

もちろん、運が良ければバグの所有者自身が必要な情報を見つける場合もあります。この場合は所有者自身で状態を ASSIGNED に変化させますが、これはあくまでも運が良かった場合のものであり、通常はこのようなことは発生しません。

なお、初期状態やバグ処理の途中で BNC-Screening-Team に割り当てられたもの (主に YaST や X11 関連の問題) に ついては、報告者や情報の提供者が NEEDINFO の状態を ASSIGNED に変化させるべきではありません。 これは、状態を変化させることで上記のチームの作業が完了したことを表わしてしまうためで、担当者の再割り当てが行なわれるためです。状態を変化させることで誤った一覧に掲載されることになるため、効率的にバグを処理できなくなってしまいます。あらかじめご注意ください。

NEEDINFO の状態のまま放置した場合の処理について

NEEDINFO の状態のまま 1 ヶ月以上放置されたバグについては、 "Resolved: NORESPONSE" (解決済み: 回答無し) として閉じられます。その際、コメントには "Requested information not provided for more than 4 weeks, closing as NORESPONSE. Please reopen the bug once the information is provided." (4 週間以上にわたって必要な情報を ご提供いただけなかったため、 NORESPONSE として閉じさせていただきました。必要な情報が揃い次第、バグを再度開いて ください) のように記入されます。

バグのスクリーニング (選別) の一環として、他の開発者がバグに対する作業を行なう場合もあります。


VERIFIED / CLOSED の状態について

新しいバージョンや更新によって問題が解決した場合、 VERIFIED や CLOSE の状態にすべきかどうか

[TBD]


WONTFIX の状態について

この説明は Bug Status WONTFIX に書かれています。


特定のバグに対する報告方法

様々なコンポーネント (カーネルや KDE, YaST など) に対するバグの報告方法について、詳しくは openSUSE:Submitting bug reports をお読みください。


openSUSE のドキュメンテーションについて

文書類の問題についても、 Bugzilla に報告してください (コンポーネントには "Documentation" を選択します) 。


ベータテスト

openSUSE のベータテストへの参加方法について

openSUSE はオープンな開発を行なっています。 openSUSE プロジェクトのメーリングリストバグレポート の説明に従ってご参加ください。

SLES や SLED などのベータテストへの参加方法について

すべての製品に対してベータテストが実施されているわけではありませんが、詳しくは The Novell Beta Program をお読みください。