I don't really care if another bug is marked duplicate of the one I am watching. There should be a preference called "Another bug is marked a duplicate" (or something like that) which I could disable.

The filtering prefs do need some refining and I've often thought this would be a nice addition, but I don't want to add anymore prefs until the backend is refined in bug 73665.

Mass moving to new product Bugzilla...

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.

Changing default owner of Email Notifications component to JayPee, a.k.a. J. Paul Reed (preed@sigkill.com). Jake will be offline for a few months.

It was for a while that I 've been thinking to file a similar bug report, thankfully I found this one. No activity since v2.16. I think it's important because of wasted bandwidth. About 1/4 ~ 1/2 of my daily bugmail is duplication notifications. I do understand that for some bug owners or reporters it's useful to be informed: if a bug has duplicates, it's importance is increased. But, my impression is that most people (incuding developers) don't like that. They are overloaded with bugmail, so they simply don't read it or they simply avoid to cc themselves to any bug. As some well known NS employe said, "it's a matter of survival". Wouldn't it be nice to make them a little more happy? Mail filtering is not a perfect solution. Besides, fixing this bug would vastly reduce bugzilla server bandwidth usage and increase its speed.

I'm not saying that the backend on this doesn't need some work, but you can't get what you want by turning off some of the notification in the current email preferences? Does turning off "When the bug is resolved/verified" help at all? A *lot* of email stuff is slated to change for 2.18... trust us, we're working on it...

JayPee, that'll only handle the bug being marked a duplicate, which you probably *do* want to get. The one you don't want is the notification on the original bug that another bug was marked a duplicate of it. Because all it is is a comment on the bug. So the only way to stop it currently is to ignore comments. Bugzilla has a very good infrastruction for handling duplicates now. The best course of action is probably to make better use of that infrastructure (the duplicates table) and make the UI use that infrastructure instead of just adding comments to the bug...

>The one you don't want is the notification on the original bug that another bug was marked a duplicate of it. This is exactly what I wanted to say. Impatiently waiting for 2.18 :-)

Well, I haven't received a single "Bug xxx has been marked as a duplicate of this bug" bugmail in the last week or so. Particularly very happy for not receiving such messages from bug 82534 (I used to get at least one per day). I think we should verify this bug as fixed.

Well, I was wrong. I got 3 bugmails from the aforementioned bug today. I had "Any field not mentioned above changes" unchecked.

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

This should wait until we have an emailprefs table, IMO - bug 73665. Gerv

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

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

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

I would assume when this is introduced there will be a way to only get duplicate reports if "real", i.e., user-typed, comments are added? Blocking all duplicate reports would eliminate these reports that have extra information, like why the bug was marked a dup. I find the extra comments interesting so I'd like to keep getting them when this gets in.

Enhancements which don't currently have patches on them which are targetted at 2.18 are being retargetted to 2.20 because we're about to freeze for 2.18. Consideration will be taken for moving items back to 2.18 on a case-by-case basis (but is unlikely for enhancements)

This is a patch implementing the described functionality. Works for me. Very small and few changes, couldn't this even go into 2.18? I appreciate any comments or field tests...

Comment on attachment 158101 [details] [diff] [review] mail-duplicates.patch This causes false positives and is a hack. We need a better infrastructure and after that we can deal with this. Feel free to provide this, by the way!

Suggested plan: -> Analyse the current DB schema and see where someone would fit a flag for "X has been marked as a duplicate of". Introduce the fields in the current schema if we have no place for it yet. You might want to put a document describing the new fields (if needed) as attachment and request review on it. -> Analyse and review things related to the email prefs (like the new email prefs table) and see how things fit in. -> Analyse and implement also a solution that would allow for the localization of the "has been marked a duplicate of" messages. -> Analyse, review and code checksetup.pl that should populate the DB field based on the existing comments. -> Finally, rewrite this patch based on the work above.

(In reply to comment #20) > Suggested plan: I'm sorry, I do not have time to re-engineer bugzilla completely.. (besides, this is done in different bugs than this here) My patch simply uses and extends the existing (apparently non localisable) code. It would introduce new functionality without any new flags/variables and only minimal code addes/changes based on the same ideas currently doing the stuff. Bug 73665 will need some more time (as for bug 100089 and blocking bug 84876); implementing this here would make people happy until those changes get in. I will love to file a new bug requesting the dep-pref as soon as appropriate, but this bug imho is a now-issue. Note this is currently the 7th most voted bug in Bugzilla's bugzilla...

I may state the obvious but the real reason of the concern and so many votes is bugzilla.mozilla.org. A quick and easy hack (applicable to bugzilla.mozilla.org only) would save a lot of bandwidth that costs money. As you all know, Mozilla organization is not backed by AOL anymore.

Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004. Anything flagged enhancement that hasn't already landed is being pushed out. If this bug is otherwise ready to land, we'll handle it on a case-by-case basis, please set the blocking2.20 flag to '?' if you think it qualifies.

Speaking as a heavy b.m.o user, this would be very useful for me; I've had about 800 dup notifications in the last year that I'd rather not have gotten. A fix would be a huge add for a huge number of users. The huge blocker bug is fixed, so you're much closer to seeing this implemented in a non-hackish way. Chances are just about nil that you'll get this for 2.20, but I can still dream. ;-) Mark this as blocking2.20+ or blocking2.20- as you think best.

"If it's not a regression from 2.18 and it's not a critical problem with something that's already landed, let's push it off." - Dave

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

I may be getting ahead of myself, but here's a patch against the current tip. It actually relies on the patch in bug 314269 landing though, so I'm going to next mark this bug as dependent upon that one. This is because of the checksetup.pl bits to initialize the settings. Since bug 314269 is the first new email setting, that's where the new block of code in checksetup is coming from. So, we need that first. Not to mention the fact that we're incrementing the value of the EVT_* stuff, and I've made this one 10 with bug 314269 (dependency changes) taking 9. Asking for review from Joel, since he's going to be reviewing the other patch as well. Todd

Comment on attachment 201279 [details] [diff] [review] patch against 2.21 (depends on bug 314269 landing) > elsif ($commentField ne '') { >- $events{+EVT_COMMENT} = 1; >+ # Since being marked as a duplicate is a specific type of comment, >+ # it's either a DUPLICATE or a COMMENT. not both. >+ if ($commentField =~ /has been marked as a duplicate of this bug\. \*\*\*/) { >+ $events{+EVT_DUPLICATE} = 1; >+ } >+ else { >+ $events{+EVT_COMMENT} = 1; >+ } I think this is a bit more error-prone than I would like. Can you do something to make sure that this is really a duplication rather than a quote of such a message? Perhaps you can ensure that the ENTIRE comment field is the duplication notation and that the bug it refers to has, in fact been marked RESOLVED DUPLICATE of this bug.

Yeah, I totally agree this needs to be more restrictive. Are you sure we need to actually verify that the bug the comment refers to is a duplicate in the database? If the entire comment matches exactly the standard duplicate messages, then it seems that should be sufficient. Here's a patch that matches either message exactly. If you *really* think I should verify against the DB, then I can add that, but it seems overkill to me. Todd

too late for 2.22; the trunk is frozen.

Comment on attachment 201311 [details] [diff] [review] v2 - ensure entire comment matches duplicate message Again, like I previously said: anybody can cheat the system implemented by this patch, by typing in the "correct" comment. I won't review+ a system that allows users so easily to generate false positives. Joel's suggestion of DB-checking looks good! :)

(In reply to comment #31) > (From update of attachment 201311 [details] [diff] [review] [edit]) > Again, like I previously said: anybody can cheat the system implemented by this > patch, by typing in the "correct" comment. I won't review+ a system that allows > users so easily to generate false positives. > > Joel's suggestion of DB-checking looks good! :) > Let me see if I follow. One of the problems here is that someone can enter a comment AND mark a bug a duplicate at the same time, so then the question is, "how do you check to see if that was what happened?" A further problem is checking whether or not they are quoting a previous comment that set the bug as duplicate, or whether or not they are trying to spoof the duplicate being set. I don't know the system very well, but I would assume that these duplicate messages are only sent out when the "Resolution" status actually changes to "Duplicate", right? So, isn't there a way to check the time when the Resolution status for a bug changed to "Duplcate", and then not send out the corresponding duplcate comment UNLESS it also contains a further comment? For the case where someone "spoofs" a duplicate by creating a post containing "*** This bug has been marked as a duplicate of bug # ***", that comment will be sent out to those who are attached to that particular bug, and not to "Bug #", correct? So that wouldn't even apply here.

This bug is retargetted to Bugzilla 3.2 for one of the following reasons: - it has no assignee (except the default one) - we don't expect someone to fix it in the next two weeks (i.e. before we freeze the trunk to prepare Bugzilla 3.0 RC1) - it's not a blocker If you are working on this bug and you think you will be able to submit a patch in the next two weeks, retarget this bug to 3.0. If this bug is something you would like to see implemented in 3.0 but you are not a developer or you don't think you will be able to fix this bug yourself in the next two weeks, please *do not* retarget this bug. If you think this bug should absolutely be fixed before we release 3.0, either ask on IRC or use the "blocking3.0 flag".

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

Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set "blocking3.2" tp "?", and either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.

There is no patch to approve.

Excuse me, I wrong flag.

The code is already frozen to prepare 3.2. We won't take any new enhancement.

We are going to branch for Bugzilla 4.4 next week and this bug is either too invasive to be accepted for 4.4 at this point or shows no recent activity. The target milestone is reset and will be set again *only* when a patch is attached and approved. I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else.