Comment 4 for bug 52613

Matthew Paul Thomas writes ("[Bug 52613] Re: "Duplicate" system is conceptually erroneous"):
> And there being no master bug report is good because someone can resolve
> a bug report by e-mail and it will Do The Right Thing, even if in the
> meantime someone else discovered that the bug had previously been
> reported and marked it as such. Is that right, and are there any other
> reasons?

It's right because the concept of the master report for a set of
merged bugs doesn't generally correspond to anything important in the
workflow. If you think about the problem clearly, then the concept of
the master report goes away. Your example of fixing the bug is just
one.

For example, obviously all reports which are of the same bug ought to
be in the same state, so it is wrong to show the states of some of
them as a special `duplicate-of-other-bug' state rather than
`confirmed', `fix released' or whatever. It should also be possible
to manipulate the state of a bug via any of its reports.

This is all complicated for Malone by Malone's task concept. I
haven't thought about this aspect clearly but the obvious answer is
that when two bugs are merged the new task list should be the union of
the existing task lists, and then from then on each set of merged bugs
should have one list of tasks shared between all of the reports.

> Please also explain the "Before bugs can be merged they must be in
> exactly the same state, either all open or all closed" part. Is that
> solely to make merging commutative? In my experience it's common for
> duplicates to be reported where the original is resolved fixed, because
> a version with the fix has not yet been released.

That feature of the `merge' command is needed to preserve the
invariant property that all merged bugs are in the same state. It is
obviously wrong for two reports describing the same bug to record it
as being in different states. The bug system should record the actual
state in the real world of the problem and its fix, and that state
exists once overall, not once for each report.

The `forcemerge' command exists precisely for the use case you
mention. The forcemerge command copies the state from the first
report mentioned to the other reports, so that they are in a suitable
state for merger. It's a convenience function.

Note that with a merge or forcemerge command both the first and
subsequent bugs mentioned may themselves already be merged with
others. With forcemerge the state of the first bug listed will be
override the prior state of all bugs which start out merged with any
of the later ones, so that the invariant is preserved.

Ian.