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)
Tracking
()
NEW
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.
Comment 1•23 years ago
|
||
*** Bug 110549 has been marked as a duplicate of this bug. ***
Comment 2•23 years ago
|
||
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
Comment 3•22 years ago
|
||
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.
Comment 4•22 years ago
|
||
Bug 68611 is relevant for a transitive closure cache of the duplicate relation.
Comment 5•22 years ago
|
||
*** Bug 186855 has been marked as a duplicate of this bug. ***
Updated•21 years ago
|
OS: Solaris → All
Hardware: Sun → All
Version: 2.15 → unspecified
Comment 6•20 years ago
|
||
*** Bug 231006 has been marked as a duplicate of this bug. ***
Comment 7•20 years ago
|
||
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.
Reporter | ||
Comment 8•20 years ago
|
||
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 ;-).
Comment 10•19 years ago
|
||
(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%?
Comment 11•19 years ago
|
||
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.
Comment 12•19 years ago
|
||
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
Comment 13•19 years ago
|
||
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.)
Updated•18 years ago
|
QA Contact: mattyt-bugzilla → default-qa
Updated•18 years ago
|
Assignee: myk → create-and-change
Comment 14•17 years ago
|
||
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?
Comment 15•17 years ago
|
||
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).
Comment 17•12 years ago
|
||
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.
Description
•