Use terms from duplicate bugs to return originals in regular searches

I'm sure omitting bugs is necessary. But Malone needs a better way of dealing with duplicates.

Say I filed a bug in package nautilus related to icon size, because it happened there, knowing not much about internals. An expert reassigns this to ubuntu-artwork and marks it as duplicate.

Another user sees the icon problem in nautilus too, but searching for bugs in package nautilus wont find an existing bug, so yet another bug duplicate is filed.

So it might be a good idea to keep a reference to places where bugs are reported, even they don't belong there. Might work with an "came-from-tag" or general tag based.

And of course, when searching for bugs with keywords all duplicates should be taken into account. The result could be showing only the main-bug noting that already #n duplicates exist.

helps reducing duplicates, makes malone more useful so it isn't just minor

When searching for dupes on bug filing--which is something I'm currently working on--I think it's better to simply search all bugs in that context, dupe or not, and display all matches.

This makes it more likely that a reporter will find the bug report (which may already be marked a dupe) describe in a way that matches the description they're carrying in their head.

In that case, we could dupe this bug against bug 996. What do you think?

> This makes it more likely that a reporter will find the bug report

It also makes it more likely that the reporter will comment to a dupe, meaning no one will care about his/her comment...

On 16-Oct-06, at 6:26 PM, towsonu2003 wrote:

>> This makes it more likely that a reporter will find the bug report
>
> It also makes it more likely that the reporter will comment to a dupe,
> meaning no one will care about his/her comment...

Good point. Should comments be allowed on duplicates?

>>> This makes it more likely that a reporter will find the bug report
>> It also makes it more likely that the reporter will comment to a dupe,
>> meaning no one will care about his/her comment...
>
> Good point. Should comments be allowed on duplicates?
>

if you could solve bug 3796 before this one, then it might not matter
(imho people tend to check the status+importance more than various
notifications about the bug). but if this one is solved first, then no
it should not be allowed :)

On 18-Oct-06, at 11:05 AM, towsonu2003 wrote:

>>>> This makes it more likely that a reporter will find the bug report
>>> It also makes it more likely that the reporter will comment to a
>>> dupe,
>>> meaning no one will care about his/her comment...
>>
>> Good point. Should comments be allowed on duplicates?
>>
>
> if you could solve bug 3796 before this one, then it might not matter
> (imho people tend to check the status+importance more than various
> notifications about the bug). but if this one is solved first, then no
> it should not be allowed :)

I agree. I think we should:

   1. Display duplicate status as "Duplicate"
   2. Allow commenting on those bugs anyway, so someone can ask "Is
this really a dupe of X?", etc.
   3. Match duplicate bugs in dupe bug searches, rather than fancily
showing only their dupe targets, so that the user may stumble on a
duplicate report that better resembles the way they experienced the bug.

Setting back to confirmed for because people have commented after Brad's question.

Since now duplicates are clearly indicated as such and the big info box should discourage people from commenting on duplicates I think this should definitely be fixed. If this was fixed, it would at least mitigate the critical bug #576956, so I consider this of high priority. Currently any information provided in duplicate bug reports (which can be substantial) is completely lost. And duplicate bug reports are impossible to find unless you happen to find the bug report they are marked a duplicate of - which can have completely unrelated title, keywords and description.

We do this in the bug filer duplicate-search step, but not in normal bugs.

s/bugs/bug searches/. Its not currently scheduled and we've stopped trying to partially-sort unscheduled work, so marking this as Low to reflect reality. Someone that wants it could create a patch to do this - it has some performance implications but not all that many - it should be quite doable.