6

I often encouter the following pattern: A bug is resolved/closed as duplicate of another still open/unfixed bug.

I have trouble understanding the reasoning behind this strategy. From my naive point of view, there is at least one major downside: there is no easy way to verify that this is really a duplicate.

Normally, there is a pretty good heuristic to check whether a bug is fixed: Just run the reproducer/broken test and see if the result is right - almost everyone can do it. However, in the case of the duplicate-closure (as long as the original bug isn't fixed), verification can be done only by understanding the code and reasoning about it - and pretty often the only person being able do it, is the person closing the bug as duplicate.

A more sensible approach could be to mark the bug as duplicate, to resolve/close the duplicate-target, and only then to resolve/close the duplicate. Now the tester can easily verify that all problems are solved by running the reproducers.

Is closing a bug as duplicate of an unfixed bug considered a standard way of handling duplicate bugs? And if yes, why is it considered to be legit?

Improve this question
1
  • A bug is a duplicate if the symptoms are the same not if the causes are the same
    – Miles Rout
    Dec 25, 2018 at 19:06

3 Answers 3

Reset to default
10

In the cases in which it is absolutely clear that the issue/root cause is the same (for example crashes with the same traceback occurring in the same conditions, only reported by different customers) yes, closing it as a duplicate is IMHO perfectly OK - tracking the 2 (or more) issues separately is just a waste of time/resources.

In other cases marking as duplicate could be done by developers with intimate knowledge of the respective code and understanding that the problem is indeed a duplicate. Debatable though - humans make mistakes.

You're right that to be perfectly correct one should only be closing a problem as duplicate only when the original problem is fixed and the fix is verified to be fixing the candidate duplicate problem as well. But that may be costly, especially if the tracking system doesn't specifically support such capability. For example tracking the actual backlog of open issues would be difficult without being able to distinguish between the "originals" and duplicates.

In some cases an acceptable compromise (also slightly debatable) is to allow marking an issue as duplicate (for cost savings), but with the submitter always retaining the right to re-open it if/when the original problem is fixed, but the issue in question is not. Typically this would be verified (usually by the original submitter) as a release gating check (if applicable).

Improve this answer
6

You want to have a clear view of the issues with a software.

If a system has 10 issues, you want 10 open bugs. Not 10.000 open bugs of duplicates.

You also want the minimum amount of administration. So closing a bug as duplicate when someone finds out it is, is the sensible thing to do. Time is expensive and you want to spend as little time as possible on duplicates.

There should however be a process to reopen your issue if the duplicate turns out not to be so duplicate.

Improve this answer
4
  • Absolutely this. I used to work with a client who would forward all user emails regarding a single bug to our ticketing system, which would go on to generate tickets for every such email trail. We would read the tickets, identify the duplicates, close them and charge him for the time to do so.
    – Ant P
    Dec 21, 2018 at 10:33
  • But how is this more advantageous than only marking this bug as duplicate and not closing it? Those duplicate-candidates are easily filtered out for the overview. Closing bug means actually spending more time, because somebody has to verify it (which is not easy if done properly). So closing a duplicate bug after the fix means you need to invest the same/or less amount of time later, because then it is much easier to verify. And you don't run the risk that it is not a duplicate after all.
    – ead
    Dec 21, 2018 at 13:01
  • @ead closing a bug as duplicate is one action. Marking a bug as duplicate, keeping it open and closing it when the issue is resolved is at the very least 2 actions. Twice the administration. I don't get where you get the "less time" from.
    – Pieter B
    Dec 24, 2018 at 9:18
  • I refer to the time spent by QA verifying the fix after the closure. If the original bug isn’t closed, it is quite hard to do.
    – ead
    Dec 24, 2018 at 10:18
0

You want a single, unambiguous, canonical place for an issue to be discussed. Having a second ticket open makes it hard to figure out which ticket is actually being used - if developer A starts looking into the issue, and leaves a comment with their progress, then you want to make sure that developer B (or developer A one week later, for that matter) sees that comment, rather than missing it because they were looking at a different ticket that describes the same issue.

Ideally, when the duplicate gets closed, any new information that ended up on it should be copied onto the original ticket.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.