I have no simple and easy ideas for avoiding duplicate reports for the same bug. Everything I write here will be obvious to the experienced bug reporter.Michael Long wrote:One thing I was thinking about when I thought about new releases of ReactOS is the problem the Debian developers have run into:
There are more bugs reported for Debian in a time span than there are resolved. This caused the situation that bugs are being reported 2 times, 3 times 5 times, ... Maybe because the bug tracker is bursting, people don't find the bugs anymore. There are just way too (many). So dozens and dozens of duplicates get flushed into the bug tracker. There are more than 80k bugs in the bug tracker of Debian and the (number is rising and rising).
They have a nice graphic for this:
[ external image ]
With ReactOS it's not as bad as it is with Debian (yet). But for example, if you open JIRA and search for unresolved bugs regarding USB then you will find about 200 bug reports. There are quite (a lot of) duplicates. USB seems to be a big desire at the moment but developers can't deliver fast enough. So we already got the situation in a small scale.
But I have no idea how to avoid such a situation especially considering that 0.5 probably means new features and new features probably mean new bugs. 0.5 probably also means more popularity and more popularity means more users and with that more bug reporters.
When making a bug report to any project, one should always search the project's existing bug reports to see if the bug has already been reported. This is a good practice and good citizenship in the open source community. Unfortunately, people unfamiliar with any bug reporting system often find JIRA to be mysterious and difficult to use. (In my opinion, to the first-time bug reporter Bugzilla is as mysterious as JIRA.)
I realize that searches of JIRA beyond a simple keyword or short string are difficult. But one can at least do some basic searching of JIRA before reporting a bug. If the bug causes an error message to appear, be sure to search JIRA for some or all of the error message's text.
Making clear and complete bug reports will help the next person who later wishes to report the same bug find the earlier report for the same bug. If the bug causes an error message to appear, be sure to include the text of the error message in the bug report. If it is short, include it in the title of the bug report. Try to use the customary names for things or behaviors mentioned in the bug report. (When making a bug report, leave blank any JIRA field that one doesn't understand. One of the developers (devs) will add any necessary bug tracking and bug assignment information to the bug report.)
Two bug reporters will sometimes describe the same bug in very different ways. If the same underlying bug causes different bad behaviors in different contexts then this could easily be reported as two different bugs. In other cases, two people see the same bug but each describe its behavior using very different words.
If software bug reporters test newer versions of the software and find that a bug they reported is no longer present then they can help flush duplicate bug reports out of JIRA. Performing a bisection to find the revision that removed the bug might help locate any duplicate reports of that bug. Then all duplicate reports of that bug can be closed as duplicates and the revision that included the fix noted in the remaining report of the bug which will then also be closed as resolved.