Bug 30345 (DupeLoop)

Can mark bugs duplicates of each other [dupe loops]

RESOLVED FIXED in Bugzilla 2.20



19 years ago
6 years ago


(Reporter: CodeMachine, Assigned: LpSolit)


Bugzilla 2.20
Dependency tree / graph
Bug Flags:
approval +
approval2.20 +


(Whiteboard: [relations:dupl] consistency)


(2 attachments)



19 years ago
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

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

Comment 2

19 years ago
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

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

Comment 4

19 years ago
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

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

Comment 6

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

Comment 7

19 years ago
tara@tequilarista.org 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 .)
Assignee: terry → tara

Comment 8

19 years ago
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

19 years ago
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 nobody@mozilla.org.  WONTFIX is only for things
that it is a bad idea to fix.

Comment 10

19 years ago
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 

Comment 11

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


18 years ago
Depends on: 25693

Comment 12

18 years ago
Adding default QA contact to all open Webtools/Bugzilla bugs lacking one.
Sorry for the spam.
QA Contact: matty

Comment 13

18 years ago
In the BZ3 world this will probably be easier (I think).
Target Milestone: --- → Bugzilla 3.2
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.
Target Milestone: Bugzilla 3.2 → Bugzilla 2.16

Comment 15

18 years ago
What do we do for existing problems?  Should there be a sanity check on
dependency relations?
Severity: trivial → normal
Priority: P3 → P2

Comment 16

18 years ago
Assignee: tara → myk
Component: Bugzilla → Creating/Changing Bugs
Product: Webtools → Bugzilla
Version: other → 2.10


17 years ago
Whiteboard: [relations:dupl]


17 years ago
Whiteboard: [relations:dupl] → [relations:dupl] consistency
I thought this wasn't possible. :-(

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.
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
No, its dependancy loops which aren't possible. Maybe that code should be made
more generic, and used here?
*** Bug 154617 has been marked as a duplicate of this bug. ***


17 years ago
Alias: DupeLoop
Summary: Can mark bugs duplicates of each other. → Can mark bugs duplicates of each other [dupe loops]
*** Bug 180403 has been marked as a duplicate of this bug. ***

Comment 22

15 years ago
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)
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
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20


14 years ago
Blocks: 271023

Comment 24

14 years ago
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 nobody@bugzilla.org 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.
Target Milestone: Bugzilla 2.20 → ---

Comment 25

13 years ago
Created attachment 194328 [details] [diff] [review]
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.
Assignee: myk → LpSolit
Attachment #194328 - Flags: review?(myk)


13 years ago
Target Milestone: --- → Bugzilla 2.20
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.
Attachment #194328 - Flags: review?(myk) → review+
Flags: approval+

Comment 27

13 years ago
we should take it for 2.20 too.
No longer depends on: 68611
Flags: approval2.20?
yeah, this looks low-risk enough to go into 2.20, and it does prevent some minor
DB corruption.
Flags: approval2.20? → approval2.20+
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

13 years ago
Created attachment 194394 [details] [diff] [review]
backport for 2.20

check_form_field_defined was CheckFormFieldDefined in 2.20.

Comment 31

13 years ago

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


Checking in process_bug.cgi;
/cvsroot/mozilla/webtools/bugzilla/process_bug.cgi,v  <--  process_bug.cgi
new revision:; previous revision:
Checking in template/en/default/global/user-error.html.tmpl;
 <--  user-error.html.tmpl
new revision:; previous revision:
Last Resolved: 13 years ago
Resolution: --- → FIXED
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.