Closed Bug 633188 Opened 12 years ago Closed 12 years ago

distinguish earlier filed "duplicate"

Categories

(Bugzilla :: Bugzilla-General, enhancement)

Other
All
enhancement
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: mrmazda, Unassigned)

Details

Good policy reasons exist to "dupe" particular older bugs to newer bugs, but this is a language misuse, since technically one cannot replicate something that did not exist previously. More importantly, the practice of duping to newer misleads as to the age of a bug that remains open or the length of time it took for a bug to get fixed. While it is possible to find the oldest dupe reading through bug comments, then open that bug to find its age, it's tedious, and won't show up in reports. I propose that some (possibly optional) new resolved status be provided (by default) for bugs duped to newer filed bugs, possibly "subsumed".
Having a separate bug status for this case won't bring any value. And we will in no case add a new one *by default*. Your solution doesn't fix the problem you describe; when viewing a bug, you still don't know what was the original bug, nor when it was created.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
I don't see how you can say there is no value in reports that indicate a bug's age correctly. This new resolved state could be added as an extra field on the bug "duped" to, as in date reported, followed by date of a subsumed bug (if applicable, which would date the problem), followed by last changed date.

Can you please explain this absence of value?
The programmatic concept for duplicating is the same in both directions, so a new resolution would be more complexity than is necessary. Generally when you think about field values, you should think about searching on them, doing metrics on them, and running reports on them. In all those cases, it's much simpler and more sensible to have just one resolution for this.

If your problem is that you want to know the oldest bug, that would be a separate problem to solve in the UI, separately.
What I'm interested in is knowing the problem's age, not the age of the bug filed by the dev who filed a new bug to attach his patch to, or the age of the newer bug filed because the old bug was too polluted to find relevant information in, or the age of some random other bug filed because its filer failed to find the original or because a triager first found some later one to dupe against.
Okay. That sounds like useful territory for a Bugzilla Extension.
You need to log in before you can comment on or make changes to this bug.