filebug duplicate finder finds 'invalid' bugs

Bug Description

Symptoms
========
Visit https://launchpad.net/launchpad/+filebug, enter 'edgy' and continue. The 8th bug on the frequently reported list is "ipw3945 not working (Edgy 2.6.17-9-generic #2 SMP)", which has been wrongly reported against launchpad and marked invalid.

What happens if a really frequently filed bug is actually a bug in something else? It will end up rejected, and yet people will go on filing new bugs because they don't see it listed.

The same argument could be made for bugs that are Fix Released -- how do we know whether the user is already using the updated version?

Ultimately, I want to understand: what is the advantage in removing items from that list?

I agree with kiko, I think this would be counter-productive.

Out of the ten bugs currently shown in <https://launchpad.net/launchpad/+filebug> (bug 135853, bug 95110, bug 62452, bug 29227, bug 6372, bug 2110, bug 2088, bug 1972, bug 1313, bug 929), nine of them (all except 29227) are irrelevant -- they're not bugs that people are at all likely to report duplicates of. We know they're irrelevant either because they were fixed long ago, or because they were declined long ago and nobody has touched them or reported duplicates of them recently. The meaning of "long ago" and "recently" differs per project. For Launchpad, we roll out monthly but occasionally skip rollouts, so we might set a boundary of 60 days. (For a similar purpose, Ubuntu might set a boundary of 1 year.)

So I think Invalid, Wontfix, or Fix Released bugs should be included in this bug listing -- or any default bug listing -- if they were changed in the last n days, where "changed" includes "had a duplicate reported", and n is set per-project. This would remove all nine irrelevant results from <https://launchpad.net/launchpad/+filebug>, because none of them have been changed in the past 60 days.

Ah, now there's a really good idea! If we can have the N days counter also reset when somebody duplicates a bug against the bug presented, then I am strongly +1 in implementing this.

We can expect bugs filed in the wrong place to be retargeted; that leaves no trace of their presence behind. Bugs with multiple tasks permit tasks to be deleted, which users are now doing. So there is no reason to believe that any invalid task is good evidence of a bug being consistently misfiled.