

Wherein reporters don't find duplicate bugs - axiak
http://code.google.com/p/chromium/issues/detail?id=66071

======
redstripe
I would call this a bug tracker fail. Having a 20,000 issues in the database
is going to lead to a lot of data duplication.

Searching for "mouse wheel scroll" produced 111 results. The chance that I
will read through all 111 of those if I am only slightly interested in the
project is: zero percent. Instead I will submit a new bug as a bit of
volunteering and leave the sorting out to the maintainers.

Not like one more dupe on a 20k list will make a difference. Broken window
theory.

At the very least they could have a prominent top 10 trending bugs list or
something. It would help keep the system from being flooded when a new build
introduces an easily triggered bug.

~~~
eli
Really, I think the problem is that it defaults to only searching Open bugs.
Makes sense, but as this case demonstrates there is a big enough gap between a
bug being fixed and an updated build getting into users' hands that there's a
problem.

I wonder how many dupes would be eliminated if the search defaulted to Open
and Recently Closed bugs.

~~~
aboodman
> I wonder how many dupes would be eliminated if the search defaulted to Open
> and Recently Closed bugs.

As of this writing, 42 out of 259 would have been eliminated:

[http://code.google.com/p/chromium/issues/detail?id=66071#c21...](http://code.google.com/p/chromium/issues/detail?id=66071#c217)

------
jey
The fix is amusing:
<http://trac.webkit.org/changeset/73619/branches/chromium/597>

~~~
nash
I'm betting the testing procedure is even more amusing.

------
gcr
"hi, i would like to check that this issue is fixed but i'm at the bottom of
that huge list of duplicates and I can't scroll up to see"

