30345 - (DupeLoop) Can mark bugs duplicates of each other [dupe loops]

Status: RESOLVED FIXED

(Bugzilla :: Creating/Changing Bugs, defect, P2)

Description

[Matthew Tuck [:CodeMachine]]

I would expect that "duplicate" would be an acyclic relation.  However, I have
marked bug #26942 and bug #30341 as duplicates of each other.

Does the bug system, know what bug something has been marked a dupe of, or is it
just "RESOLVED/DUPLICATE", with an annotation?

Comment 1

[Jesse Ruderman]

Isn't that what VERIFIED/DUPLICATE is for? To indicate that the "duplicate" 
mark is correct?

Comment 2

[Matthew Tuck [:CodeMachine]]

Yes, but there is no need to bother the verifier in this situation since it is
invalid.  It's better for the resolver to find out immediately they did the
wrong thing.

Comment 3

[Jesse Ruderman]

Well.. the "verifier" of a duplicate is usually the owner of the "original" bug.

Comment 4

[Matthew Tuck [:CodeMachine]]

Sorry, I'm not sure what you're saying.

If you're saying that it's the same person as the resolver, all the more
important to do this since they might miss it otherwise.

If you're saying that it's the owner of the bug that it has been marked a
duplicate of, I've never noticed that happening (but then I might not have been
looking), but in any case I'm not sure how it would affect my previous comment.

I was under the impression this is the job of the QA contact.

Comment 5

[Jesse Ruderman]

It's usually the owner of the bug it has been marked a duplicate of.. see my 
bug #29731 for an example.

Comment 6

[Jesse Ruderman]

Err, never mind, he was the QA contact for that one too.. hmm. Maybe you're 
right.

Comment 7

[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 8

[Chris Yeh]

i can see where this would be bad, but i also see it as 
a) an edge case
b) trying to prevent stupidity above and beyond normal.

i'm tempted to mark this as won't fix, please comment.

Comment 9

[Matthew Tuck [:CodeMachine]]

Eh?  This is a bug in Bugzilla!  We're well aware it's trivial, that's why it
says "trivial" in the severity!

Please stop stomping on bugs you don't want to fix with WONTFIX.  If you don't
want to fix it, reassign it to [e-mail].  WONTFIX is only for things
that it is a bad idea to fix.

Comment 10

[Chris Yeh]

sorry, you're right, this should be fixed. please don't spit bile at me while 
making comments though. it's hard walking through 400 bugs.

fixing this is really hard, because there's no easy way of being able to walk 
the database and figure out how a bug got closed as a duplicate of another one 
without doing additional queries in bugs activity or in the comment logs, which 
are the only two places that duplicates are regarded afaik.

thanks for the comment i was asking for. please turn down the anger setting 
though.

Comment 11

[Jesse Ruderman]

this would be pretty simple with bug 25693 (keep track of what is a duplicate 
of what, and count duplicates).

Comment 12

[Stephan Niemz]

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

Comment 13

[Matthew Tuck [:CodeMachine]]

In the BZ3 world this will probably be easier (I think).

Comment 14

[Dave Miller [:justdave]]

This needs to be fixed in 2.x.  This can cause some looping problems if anyone 
does any reports on duplicate trees with the new duplicates table.

Comment 15

[Matthew Tuck [:CodeMachine]]

What do we do for existing problems?  Should there be a sanity check on
dependency relations?

Comment 16

[Zach Lipton [:zach]]

moving

Comment 17

[Gervase Markham [:gerv]]

I thought this wasn't possible. :-(

Gerv

Comment 18

[Dave Miller [:justdave]]

We are currently trying to wrap up Bugzilla 2.16.  We are now close enough to
release time that anything that wasn't already ranked at P1 isn't going to make
the cut.  Thus this is being retargetted at 2.18.  If you strongly disagree with
this retargetting, please comment, however, be aware that we only have about 2
weeks left to review and test anything at this point, and we intend to devote
this time to the remaining bugs that were designated as release blockers.

Comment 19

[Bradley Baetz (:bbaetz)]

No, its dependancy loops which aren't possible. Maybe that code should be made
more generic, and used here?

Comment 20

[Bradley Baetz (:bbaetz)]

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

Comment 21

[Simon Montagu :smontagu]

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

Comment 22

[Stephen Lee]

With a fix for bug 68611 in place, the check here would become a matter of 
whether the end-of-chain is equal to the bug that you are attempting to resolve 
duplicate. (i.e. a single straightforward comparison)

Comment 23

[Dave Miller [:justdave]]

All 2.18 bugs that haven't been touched in over 60 days and aren't flagged as
blockers are getting pushed out to 2.20

Comment 24

[Max Kanat-Alexander]

This bug has not been touched by its owner in over six months, even though it is
targeted to 2.20, for which the freeze is 10 days away. Unsetting the target
milestone, on the assumption that nobody is actually working on it or has any
plans to soon.

If you are the owner, and you plan to work on the bug, please give it a real
target milestone. If you are the owner, and you do *not* plan to work on it,
please reassign it to [e-mail] or a .bugs component owner. If you are
*anybody*, and you get this comment, and *you* plan to work on the bug, please
reassign it to yourself if you have the ability.

Comment 25

[Frédéric Buclin]

Attachment: patch, v1

Checks whether a loop would be generated. I added a protection to the
validation to prevent an infinite 'while' loop for installations which already
have loops.

Comment 26

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 194328 [details] [diff] [review]
patch, v1

>+  [% ELSIF error == "dupe_loop_detected" %]
>+    [% title = "Loop detected among duplicates" %]
>+    You cannot mark [% terms.bug %] [%+ bug_id FILTER html %] as
>+    a duplicate of
>+    [% IF dupe_of == bug_id %]
>+      itself
>+    [% ELSE %]
>+      [%+ terms.bug %] [%+ dupe_of FILTER html %], else
>+      a loop would be generated
>+    [% END %].

Nit: "You cannot mark <bug> as a duplicate of <bug> because it would create a
duplicate loop."

Otherwise looks good, r=myk.  Thanks for the fix!  I like knocking down these
five-digit bugs.

Comment 27

[Frédéric Buclin]

we should take it for 2.20 too.

Comment 28

[Dave Miller [:justdave]]

yeah, this looks low-risk enough to go into 2.20, and it does prevent some minor
DB corruption.

Comment 29

[Dave Miller [:justdave]]

based on the type of changes required to make this apply to 2.20 I'd appreciate
getting a separate patch posted here for 2.20

Comment 30

[Frédéric Buclin]

Attachment: backport for 2.20

check_form_field_defined was CheckFormFieldDefined in 2.20.

Comment 31

[Frédéric Buclin]

tip:

Checking in process_bug.cgi;
/cvsroot/mozilla/webtools/bugzilla/process_bug.cgi,v  <--  process_bug.cgi
new revision: 1.283; previous revision: 1.282
done
Checking in template/en/default/global/user-error.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/global/user-error.html.tmpl,v
 <--  user-error.html.tmpl
new revision: 1.122; previous revision: 1.121
done


2.20rc2:

Checking in process_bug.cgi;
/cvsroot/mozilla/webtools/bugzilla/process_bug.cgi,v  <--  process_bug.cgi
new revision: 1.263.2.2; previous revision: 1.263.2.1
done
Checking in template/en/default/global/user-error.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/global/user-error.html.tmpl,v
 <--  user-error.html.tmpl
new revision: 1.115.2.4; previous revision: 1.115.2.3
done