9403 - Marking a bug as duplicate of another bug should mark bugs blocked by it as depending on the other bug

Status: NEW

(Bugzilla :: Creating/Changing Bugs, enhancement, P3)

Description

[John G. Myers]

If bug A depends on bug B, then bug B is resolved as a duplicate of bug C,
bugzilla should probably change bug A to depend on bug C.

Comment 1

[Matthew Tuck [:CodeMachine]]

Yeah, but what if it is reopened?  I see dupes being resolved wrong all the
time.  A better policy would be to add the new bug, but not remove the old one,
although there are still some problems with this.

Comment 2

[Ben Bucksch (:BenB)]

*** Bug 13629 has been marked as a duplicate of this bug. ***

Comment 3

[Ben Bucksch (:BenB)]

*** Bug 32944 has been marked as a duplicate of this bug. ***

Comment 4

[Terry Weissman]

[e-mail] is the new owner of Bugzilla and Bonsai.  (For details,
see my posting in netscape.public.mozilla.webtools,
news://news.mozilla.org/38F5D90D.F40E8C1A%40geocast.com .)

Comment 5

[Stephan Niemz]

Adding default QA contact to all open Webtools/Bugzilla bugs lacking one.
Sorry for the spam.

Comment 6

[Matthew Tuck [:CodeMachine]]

Moving this to Future to get off the radar, although I think this should be
WONTFIX.

Comment 7

[Matthew Tuck [:CodeMachine]]

-> component owner

Comment 8

[Daniel (Leaf) Nunes]

This should definitely not be wontfix; if bugzilla is going to be used for
project management, this is a key feature. The simple way would be to just add
the "original" bug (bug C in jgm's example) to the dependency list; the more
complicated way is to add dependency list history to bugs, so if they get
reopened  (unduped) they can be re-added to a previous dependency list (while
still leaving bug C in the list, on the presumption that if it's as
serious/relevant as bug B, it should be there)

Comment 9

[timeless]

now that bugs actually know what they're duplicates of we should be able to have
shadow dependencies.

From the original example
A should have "Bug A depends on: D [D         ] and B: C."
C should have "Bug A blocks: E [E         ] and B: A."

Where D and E are two other bugs which are actually direct dependencies of A and
C respectively.

One thing which we could do is set it up so that Verifying a duplicate changes
the shadow dependencies to real dependencies.

Comment 10

[Travis Chase]

Adding Bug 86328 to depends. 86328 is similar to this, in that it is looking for
a way to update depending bugs, but when you delete them. So a solution, there
would make this a seemingly trivial fix.

Comment 11

[Dave Miller [:justdave]]

Travis: not even close.  That bug is talking about referential integrity in the
database, not bug dependencies.

Comment 12

[Frédéric Buclin]

*** Bug 243200 has been marked as a duplicate of this bug. ***

Comment 13

[Stephen Lee]

Now that we have a duplicates table, it is "easy" to detect that a bug is a
duplicate, and what it is a duplicate of...

... so rather than updating the records on bug A, it could remain depending on
bug B, and then have bug C act similarly to as if it was bug B for the purpose
of affecting bug A:

e.g. when Bug C changes state, dependencies get an email message:
Bug X depends on bug C, which changed state.

So by extension you could have:
Bug A depends on bug B;
Bug B is a duplicate of bug C, which changed state.

or even:
Bug Y depends on bug Z;
Bug Z is a duplicate of bug B;
Bug B is a duplicate of bug C, which changed state.


Similarly on the bug page for bug A itself, rather than just "Bug B" in the
dependency list, it could show "Bug B → C", etc.

Furthermore, on bug C, you could show duplicates (beside the "depends on" and
"blocks" section) together with "inherited" dependecies that belong to those bugs.

Idea needs fleshing out a bit, but I think it allows more consistency and
reversibility than automatically changing the target bugs, as well as better
traceability of why bug A depends on bug C.

Comment 14

[Wayne Mery (:wsmwk)]

STM this should be marked a dup of bug 65382

Comment 15

[Jesse Ruderman]

or a dup of bug 523791

Comment 16

[Frédéric Buclin]

Attachment: (wrong patch)

We shouldn't alter the DB, because the duplicate may be reopened and dependencies would then be wrong. I simply reuse the existing _resolve_ultimate_dup_id() method we have.

Comment 17

[:glob ✱]

(In reply to Frédéric Buclin from comment #16)
> Created attachment 610080 [details]
> patch, v1
> 
> We shouldn't alter the DB, because the duplicate may be reopened and
> dependencies would then be wrong. I simply reuse the existing
> _resolve_ultimate_dup_id() method we have.

that's quite different from what this bug was asking for before the subject was changed; however i agree that it would be better to make this a non-db-altering action.

with your patch i followed the steps outlined in comment 0, however i don't see anything different on the display of the duplicate on bug C (or and bugs).

Comment 18

[Frédéric Buclin]

(In reply to Byron Jones ‹:glob› from comment #17)
> with your patch i followed the steps outlined in comment 0, however i don't
> see anything different on the display of the duplicate on bug C (or and
> bugs).

Right, I misread what this bug was about. I had duplicates of duplicates in mind, not dependencies. I attached the patch to the wrong bug. Sorry.

Comment 22

[fupeng]

Attachment: Spam

Comment 23

[jasonnevanss]

Attachment: Overview: refers to a recurring issue encountered in Bugzilla, the bug tracking and reporting system. This problem affects the functionality, usability, or performance of Bugzilla, leading to challeng

Comment 24

[jasonnevanss]

Comment on attachment 9337358 [details]
Overview: refers to a recurring issue encountered in Bugzilla, the bug tracking and reporting system. This problem affects the functionality, usability, or performance of Bugzilla, leading to challeng

(spam)