277917 - Multi-branch bugs provoke duplicate reports because they do not have a status per branch and version

Status: RESOLVED DUPLICATE of bug 55970

(Bugzilla :: Creating/Changing Bugs, enhancement)

Description

[Maurice Lanselle]

A bug report is assigned one product, one version, one status.  If and when
branching occurs prior to verified fixed resolution, the report seems not to be
replicated for each branch.  Then when the status is "RESOLVED" in only one
branch (or trunk) an ambiguous or even misleading situation arises: who knows
where it has been fixed and where it has not?  This is "tracking"? It certainly
is not very obvious for reporters. For example, bug 97283 was fixed in Mozilla
in August, 2004, but was reported more than twenty more times, probably mostly
in Firefox (where it still wasn't fixed in 1.O). This results in a great waste
of reporter effort (after not finding the bug in an "open" status, one then
invests in reporting, test case, etc), bad temper ("Duplicate"? Are you accusing
me of not searching first? Of not searching well?), and possibly loss of
motivation to search at all (why bother? And "Resolved"? It still bugs with last
night's build, what do you mean "Resolved"?).

Basically, any branch (and version) should inherit any and all bug reports from
its parent, which it can then resolve for its descendants. An alternative would
be a status per product/version or product/version/platform, rather than a
separate bug.  Tracking a separate bug for each case would have the advantage of
specificity, at the risk of possibly not transferring and re-using resolutions
across multiple branches. If the specificity option is preferred, linkage to the
parent (and peer) bugs should be automatically maintained to facilitate re-use
of solutions.

Comment 1

[timeless]

i disagree.

Comment 2

[Frédéric Buclin]

you can also use flags to mark which branches are fixed and close the bug only
when all branches are fixed.

Comment 3

[Frédéric Buclin]

legitimate preoccupation. The way to fix this problem needs to be discussed though.

Comment 4

[Daniel Veditz [:dveditz]]

see also bug 55970, bug 79964 and bug 336790 for various proposals to solve the same basic problem. Also bug 267874