バグレポートの重複を避ける


9

私は自宅でLinuxなどのオープンソースソフトウェアを使用しています。私はプロのコーダーではないので、自分のスキルでは自分で問題を解決するのに十分ではないため、通常は開発者にバグを報告します。

バグレポートを送信する前に、どのようなことを確認してほしいですか?つまり、Geditでバグを見つけたと思ったら、Bugzillaで同様のバグを見つけることができませんでした。しかし、私がレポートを送信した後、バグはGeditではなくGTK +にあったため、バグはすでにBugzillaにあると一部の開発者は述べました。時々、既知のバグが私が見つけた問題を解決するかどうかをアマチュアが推測するのは難しいかもしれません。


4
今、バグレポートを追加しましたし、それはバグの重複として閉じられたことを実現し、後で通り抜ける他の誰かがします、あなたが提出されていること重複バグレポートを見つける(と別のものを提出する必要はありません)。

回答:


15

重複するバグレポートを送信しても問題はありません。類似のバグを検索しても重複が見つからない場合は、バグレポートを送信するのが最善の方法です。発生する可能性のある最悪の事態は、製品に取り組んでいる開発者がレポートを重複として閉じることです。これは、本物の問題に気付かれないようにするよりもはるかに優れています。

また、専門分野外の問題を深く調査しようとしないのも正しいことです。私の経験では、何が起こっているのか、そしてそれを修正する方法についてのユーザーの評価はほとんど間違っており、ほとんど役に立ちません(Jeffの投稿の#4を参照)。


5
「ほとんど間違っており、ほとんど役に立たない」ための+1。アーメン、兄弟。私は顧客に「解決策ではなく問題をもたらす」と言います。
Peter Rowell、

4
特にオープンソースでは、重複したバグレポートを軽蔑して扱う開発者に時々出くわすと思います。彼らは単に悪い日を過ごしているかもしれませんし、バグレポートの価値を認識するために自分たちの懸念(例:膨大な既存のToDoリスト)に集中しすぎているかもしれません。 (おそらく、使用する検索用語がすでにわかっているためです)。理由が何であれ、気分を悪くさせないでください。バグを報告することは依然として正しいことです。
John Bartholomew
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.