Duplicate bugs shouldn't show the bugtask table

[Martin Albisetti]

When looking at a dupe bug, since you can't edit it's status, there's no benefit in showing them.
Instead of the bugtask table, we should point in big letters toward the duped bug.

[Eleanor Berger (intellectronica)]

I wonder if this won't make the process of de-duping bugs more difficult. We must have enough information in front of us when we decide whether a bug really is a duplicate, and having no access to the bug tasks might make it more difficult.

[Martin Albisetti (beuno)]

Hopefully, your concern can be addressed by fixing bug #317258 instead.

[Matthew Paul Thomas (mpt)]

The context table used to be hidden in duplicate bug reports. I un-hid it, and greyed it out instead, for two reasons.

First, the information is often useful in telling whether a duplicate marking is correct. If the duplicate is In Progress while the dup target is New, or the duplicate is assigned to someone while the dup target is not, or the duplicate is milestoned while the dup target is not, then the duplicate has most likely been marked in the wrong direction and the bug would be fixed faster if the direction was reversed. If QA people cannot see any of that information, they can't tell whether they should do that.

Second, where work is accidentally being done in parallel, the duplicate information needs to be merged usually by people other than those marking the duplicate. For example: Bug X is assigned to Fred, Confirmed, and targeted at milestone 1.2. Bug Y is assigned to Samantha, and In Progress, but targeted to 1.3. The reports are duplicates. Who should the winning report be assigned to? And if it is assigned to Samantha since she's started on it already, but she says she's unlikely to get it finished this cycle, which milestone should it be targeted to? A project manager or maintainer can make those decisions, but the QA minion who marks the duplicate probably cannot. QA people shouldn't have to feel hesitant about marking duplicates because they'll be hiding information that would be useful to managers or maintainers hours or days later.

[Martin Albisetti (beuno)]

You have a good point Matt.
I'll play around with different ways of doing this so we can address all the problems. Thanks for the input.

[Matthew Paul Thomas (mpt)]

I agree that the duplicate target should be more visible than it is now, though. When Graham lands the duplicate-marking interface I designed and he started implementing last June, you might find that this is one of the things the new design achieves.

[Deryck Hodge (deryck)]

Picking up this work from Martin, which will also fix some other RC issues with dupe handling on the new version of the bug page.

[Deryck Hodge (deryck)]

This is too involved for an RC fix this week. Will continue the work, though, and land early next cycle.