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?
Isn't that what VERIFIED/DUPLICATE is for? To indicate that the "duplicate" mark is correct?
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.
Well.. the "verifier" of a duplicate is usually the owner of the "original" bug.
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.
It's usually the owner of the bug it has been marked a duplicate of.. see my bug #29731 for an example.
Err, never mind, he was the QA contact for that one too.. hmm. Maybe you're right.
email@example.com 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
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.
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 firstname.lastname@example.org. WONTFIX is only for things that it is a bad idea to fix.
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.
this would be pretty simple with bug 25693 (keep track of what is a duplicate of what, and count duplicates).
Adding default QA contact to all open Webtools/Bugzilla bugs lacking one. Sorry for the spam.
QA Contact: matty
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
What do we do for existing problems? Should there be a sanity check on dependency relations?
Severity: trivial → normal
Priority: P3 → P2
Assignee: tara → myk
Component: Bugzilla → Creating/Changing Bugs
Product: Webtools → Bugzilla
Version: other → 2.10
Whiteboard: [relations:dupl] → [relations:dupl] consistency
I thought this wasn't possible. :-( Gerv
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. ***
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. ***
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
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 email@example.com 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 → ---
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
Status: NEW → ASSIGNED
Attachment #194328 - Flags: review?(myk)
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+
we should take it for 2.20 too.
No longer depends on: 68611
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
Created attachment 194394 [details] [diff] [review] backport for 2.20 check_form_field_defined was CheckFormFieldDefined in 2.20.
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: 220.127.116.11; previous revision: 18.104.22.168 done
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.