Open Bug 108983 Opened 23 years ago Updated 1 year ago

CCed users on duplicate bug should be CCed on original

Categories

(Bugzilla :: Creating/Changing Bugs, enhancement)

2.10
enhancement
Not set
normal

Tracking

()

People

(Reporter: mozilla-work, Unassigned)

References

Details

If you are the reporter of a bug that is marked a duplicate of another bug, the reporter is CCed on the original bug. However, the CC list isn't. Typically what I do is when I file a bug from work I CC my home e-mail address. If it is marked duplicate, I wan't both addresses CCed on the original bug.
*** Bug 110549 has been marked as a duplicate of this bug. ***
Back when we added the ability to automatically cc the reporter there was a lot of objection to bringing over the cc list, but none for the reporter (see bug 28676). So, we implimented it w/only the reporter being brought over. Until we have a better system for user prefs (bug 98123) we can't bring accross cc lists...
Depends on: 98123
It would be another possibility to actually pick up the lists of dupes but not bring them over. So if you you undupe it would undo. However this would require a transitive closure cache of the duplicate relation.
Bug 68611 is relevant for a transitive closure cache of the duplicate relation.
*** Bug 186855 has been marked as a duplicate of this bug. ***
OS: Solaris → All
Hardware: Sun → All
Version: 2.15 → unspecified
*** Bug 231006 has been marked as a duplicate of this bug. ***
This might be a separate issue, but it is related. Since the reporter is being CC'd on duplicates, would it make sense, if not copying the entire CC list to copy the reporters of all bugs marked as duplicates or duplicates of duplicates, etc. of this bug? In other words, if bug 123 with reporter r123 is marked as a duplicate of bug 12 with reporter r12, r123 is copied to bug 12. However, if bug 12 is later marked as a duplicate of bug 1, both r12 and r123 should be copied to bug 1.
Re comment #7: Shouldn't this happen automatically if all CCers are copied on the duplicate bug. They are now CC'ed on bug 12 so they should get CC'ed on any bug it is marked a duplicate of.
mcalmus@nyx.net: that has the same problem as copying over the cc list. what if the dupe is bad. imagine 20 bugs are duped (properly) to one bug. and that bug is duped improperly to another bug. then this resolution is undone. you now have *20* people who may but probably do not care about a bug. and you don't really know if they care. wrt comment 0. just make your home address watch the other address ;-).
(In reply to comment #9) > mcalmus@nyx.net: that has the same problem as copying over the cc list. what if > the dupe is bad. > > imagine 20 bugs are duped (properly) to one bug. and that bug is duped > improperly to another bug. then this resolution is undone. you now have *20* > people who may but probably do not care about a bug. and you don't really know > if they care. I won't address timeless' nasty case above - ouch - except this "you now have *20* people who may but probably do not care about a bug." IMO if the bug were close enough be duped that there is an even chance one does care and would want to stay cc. Back to original topic. I'm coming from the perspective operating a couple years of in bugzillaland and just discovered I don't get cc:ed to the "dup of" when a bug is duped (unless I was the author). So I'm curious... I wonder which medicine is worse - * the multitudes of bugs that get duped and stay dup and the people who then don't get cc:ed to the "active" bug, or * the nn that get duped and don't stick, and the people who are then incorrectly retained as cc on the "duplicate of"? Two solutions that may be better than the status quo: a) include the text "you are not being cced to bug xxx" along with the "this bug has been marked as a duplicate of xxx" b) cc people to the bug xxx, and in the event the bug yyy is subsequently unduped, a message to the cc list of bug yyy that "... you might want to remove yourself from the cc list of xxx" Moving on to an unscientific study - of Firefox bugs presently open and marked: * REOPENED 79, 21 were marked at one time as dups = ~25% * ASSIGNED 169, 3 were marked at one time as dups = ~2% * NEW ~2420, 49 were marked at one time as dups = ~2% * UNCO ~5050, 48 were marked at one time as dups = ~1% bugs marked FIXED in the last 90 days: * FIXED 456, 17 were marked at one time as dups = ~4% I'm sure the stats above are not an accurate reflection of the % that are incorrectly duped, because there are too many variables. And it's not possible to quantify all the nuances (esp bugs that are now closed), for example bugs were duped, reopened and reduped, etc. Do the stats above look reasonable and suggest something close to reality? If so then the number that are unfairly duped, i.e. get unduped and go on to final closure as resolved (forgeting the multitudes that will stay forever as UNCO), is relatively small. 5%, 10%?
you're missing a couple of big items. 1. most bugs relating to firefox that matter end up in core, so your sample is horribly skewed. 2. bugs in core are often triaged and cascading dupes really happen a lot. 3. accidental dupes happen often enough even with those cascaded bugs, they often happen because of typos or clipboard glitches involving active qa people who tend to shuffle a bunch of open windows/tabs with 10 or more bugs that they're triaging. 4. firefox doesn't get much qa at all, so you're less likely to have duplicates of any kind :). now... should people get a message about a bug being fixed if they're cc'd to a dupe of it? probably, it should be like any other dependency in that respect, and it almost certainly isn't.
I think that we should add this as a global parameter. People could turn it on locally if that's the behavior they'd like for their company. The major problem is un-duping bugs, and the CCs staying around. People on the CC list get a notification when a bug is duped; they can add themselves to the new bug if they'd like. But I can imagine some installations would always like to add the CCs. So it should be a parameter.
Severity: normal → enhancement
Version: unspecified → 2.10
The problem with bad dupes (and any other irreversible corruption) would be addressed if, instead of importing the Cc list, it stayed where it was but dupes were traversed during the e-mail stage. I think this is what comment #3 means. I don't know how bugzilla's back-end works, but since e-mail is asynchronous, this work could in principle be queued for later and so a "transitively closed" cache is not strictly required. (The dupe structure could be re-traversed each time.)
QA Contact: mattyt-bugzilla → default-qa
Assignee: myk → create-and-change
uh. what do you mean email is asynchronous? in our world it's very synchronous. and keep in mind that you don't really want it to be *too* asynchronous. bug 2 duplicate of bug 1 with cc B, D bug 1 changed by person A bug 2 changed by person C to include CC for person C. bug 2 changed by person D to remove CC for person D persons B and D but no person C should get a bugmail about the change by person A to bug 1. If you make things *too* asynchronous, the wrong thing happens here. We already have a certain level of transitivity involving dependencies. It should be tolerable to walk duplicates in addition to dependencies. Except it'll get messy when you resolve a bug as fixed. bug 2 duplicate of bug 1 with cc B, D bug 2 blocks bug 1 bug 1 changed by person A to RESO FIXED step 1: generate a mail that says bug 1 is FIXED step 2: generate a mail that says bug 2's duplicate was FIXED step 3? generate a mail that says bug 1's blocker had a transition for its duplicate to FIXED ?? we certainly have to do: bug 3 duplicate of bug 2 bug 2 duplicate of bug 1 bug 1 changed by person A to RESO FIXED step 1: generate a mail that says bug 1 is FIXED step 2: generate a mail that says bug 2's duplicate was FIXED step 3: generate a mail that says bug 3's duplicate chain was FIXED. and this is relevant because bug 3 is a duplicate of bug 2 and bug 2 is a duplicate of bug 1. Note that it's hard (if not impossible) to argue against sending dependency mails for duplicates. Which takes you back to my first trio. Do you really send a second mail for bug 1 saying that a circular dependency (this form is actually very common, people tend to make a chain and then decide the bugs are the same w/o cutting the chain) has resolved itself? If not, why not?
By asynchronous I mean that a message can be sent after the initiating action is completed. The initiation doesn't have to block until all the mail is sent: mail is queued in the backend anyway. So it doesn't have to block until all the resolution is done either. That's not the same as saying the delay can be extremely long (although personally I don't think it matters very much if you get a few additional messages after removal from the list: it's not as if you were never interested).
I see 2 solutions here : 1) A complete solution would be to add a cc list, tagged by the duplicate bug number, to the bug duplicated. (A linked list of duplicate bug with corresponding cc's.) To avoid duplicate emails, scan the duplicated bug cc list to remove duplicate cc's. Then if the duplicate is removed, we simply remove the duplicate cc list as well. 2) An alternate approach would be to add a link on each cc email, "remove me from the cc list of this bug". And simply add all emails to the cc list of the bug duplicated. In most cases this will be correct, and if not, readily rectified. An additional advantage of doing this is that often someone can tire of following a bug, and thus readily cancel the cc without bothering to log in. So this would be useful in any case.
You need to log in before you can comment on or make changes to this bug.