Currently, if someone adds/removes themselves to a CC, changes a dependancy, or keyword You get a the three column "What | Old | New" stuff. On bugs with high amounts of dependencies, CC's and/or keyword this can make it very difficult to figure out what really changed. I wrote a patch that uses a sort of parsing to figure out what really changed between $old and $new and then using FormatDouble to include it in the BugMail. I set it up to work with BugsThisDependsOn, CC, Keywords, OtherBugsDependingOnThis. I also made a change in the FormatDouble subroutine to make it visually similar to FormatTriple.

Adding patch keyword and "block" status on bug 53044.

Just as I was afraid of... it crashed... :(

Oops... I typed that comment in the wrong window!! It was supposed to go into my test bugzilla db. Sorry...

The 11/22 patch doesn't work. There are a couple missing commas and a logic error. As soon as cvs-mirror is back up (see bug 62130), I'll pull of DIFF of my latest (and working) changes.

Is this a dupe of bug #30359?

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

I marked 30359 a dupe of this one 'cause this one has the patch. As I mentioned there, I'll update this patch after dmose lands his mail filtering stuff.

-> jake

Just attached patch v3 to update to the CVS tip (after bug 17464 landed). I also used Dan's new filterExcludeList() subroutine instread of the "if (!($new =~ /$val/)) {" like I was before (this cleared up the problem where if you were changing from rtm- to rtm it wouldn't pick up on the change). The e-mail is essentially the same as shown 12/8.

Is this patch just going to rot? This would be rather nice to have :)

I agree this would be nice to have (enough to write the patch, at least :). 2.12 is predicted for RSN and thus should have anything else added to its list. Nominating for 2.14.

moving to real milestones...

Great, so it will take at least another seven months, if not much longer, until I can really see again which changes were made in the CC field of a bug with lots of CCs. At the moment, bugmails (and show_activity.cgi output) regarding CC changes are rather useless. And as the popularity of Mozilla increases, the number of bugs with a huge CC list increases as well. This is frustrating. Please either include more submitted patches in 2.12 or bring out releases much more frequently. See also http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/x147.html Currently there are at least 40 bugs outside the 2.12 target milestone with a patch attached. The list is here for your convenience: http://bugzilla.mozilla.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Webtools&component=Bugzilla&target_milestone=---&target_milestone=Future&target_milestone=Bugzilla+2.14&target_milestone=Bugzilla+2.16&target_milestone=Bugzilla+2.18&target_milestone=Bugzilla+3.0&target_milestone=Bugzilla+3.2&keywords=patch%2Creview&keywords_type=anywords And sorry for the offtopic rant.

Can someone please paste what an email with this looks like. I want to make sure all the issues raised in the dupes are covered.

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

matty@chariot.net.au: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=20362 The e-mail produced by patch v3 is almost identical (very minor formating differences).

Do we really need to spray all the old values everywhere, especially with CC? Also correct me if I'm wrong but AFAICS this does nothing to align each email address on a new line which would be ten times more readable, yet dupes have been marked of this which ask for that.

I kinda went back and forth on the inclusion of the current Old/New columns. At this point in time I think the best bet would be to change the bug activitiy from the current Old/New style to a Removed/Added style (which has been discussed in IRC before).

We might want to eventually add support to let users customise this as follows: Field X: [ ] Always show. [ ] Show entire field on changes to field. [ ] Show just changes to field. (2) would only appear for list fields because the others aren't relevant. There is significant support for (1) around in various bugs for different fields.

See also bug 28736, which would make dependency changes more readable by including the summary of the other bug and maybe also a link.

couldn't the patch be implemented and fine-tuned later? Checking dependencies has become very difficult on long lists (meta bugs) ;)

Myk, see comments from st.n@gmx.net 2001-02-28 08:44 in this bug about the "help getting the backlog of existing patches for bugzilla reviewed and checked in" challenge.

While not a direct duplicate, I believe bug 55161 is the better way to fix this (and was going to morph this bug into that concept before I stumbled accross that one [OK, before Matthew targeted it so it appeared in my Inbox]). While that nullifies the patch here, I think it's better in the long run. *** This bug has been marked as a duplicate of 55161 ***

Bug 55161 fixed the *activity* display, but not the email format. Can we get the e-mail format updated the same way?

The e-mail data is pulled directly from the activity log, so this was fixed by bug 55161 (to test this, try http://landfill.tequilarista.org/bugzilla-tip/ as mozilla.org hasn't updated yet.) *** This bug has been marked as a duplicate of 55161 ***

moving to Bugzilla product reassign to default owner/qa for INVALID/WONTFIX/WORKSFORME/DUPLICATE

Verified dupe