Kevin Benton | 1 Dec 2004 21:27
Picon
Favicon

Patch query - single email per bug

Has anyone written a patch to make BZ send just one email per bug?  I
have one here as a local customization.  It allows our mail servers to
kill some of the duplicate emails that are going out (due to members of
lists getting notified along with being included for other reasons). 
It's also reducing the load on the server because it only makes one call
to sendmail instead of one per recipient.  I'd like to include it in the
public release.

Before I send it up for review, I wanted to get feedback on the idea
first.  I plan to implement a flag to enable/disable this feature named
OneEmailPerBug with a status of on/off.

Kevin

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+jYtjvyW6yDsg <at> public.gmane.org>

J. Paul Reed | 1 Dec 2004 21:32
Gravatar

Re: Patch query - single email per bug

On 01 Dec 2004 at 13:27:39, Kevin Benton arranged the bits on my disk to say:

> Before I send it up for review, I wanted to get feedback on the idea
> first.  I plan to implement a flag to enable/disable this feature named
> OneEmailPerBug with a status of on/off.

The reason, IIRC, that we didn't do this is because of the
X-Bugzilla-Reason: header, and the fact that we wanted mail sent to people,
not to a list of people.

If you can resolve the fact that you'd have to send email to classes of
people (owner, all CC list, etc.), then it should be an acceptable
optimization.

Later,
Paul
------------------------------------------------------------------------
J. Paul Reed -- 0xDF8708F8 || preed@... || web.sigkill.com/preed
Math, my dear boy, is nothing more than the lesbian sister of biology.
                                            -- Peter Griffin, Family Guy

I use PGP; you should use PGP too... if only to piss off John Ashcroft
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+jYtjvyW6yDsg <at> public.gmane.org>

Kevin Benton | 1 Dec 2004 21:40
Picon
Favicon

Re: Patch query - single email per bug

That's exactly what we've been doing here and also the reason why I'd
add the config flag to enable/disable it.

Kevin

On Wed, 2004-12-01 at 13:32, J. Paul Reed wrote:
> On 01 Dec 2004 at 13:27:39, Kevin Benton arranged the bits on my disk to say:
> 
> > Before I send it up for review, I wanted to get feedback on the idea
> > first.  I plan to implement a flag to enable/disable this feature named
> > OneEmailPerBug with a status of on/off.
> 
> The reason, IIRC, that we didn't do this is because of the
> X-Bugzilla-Reason: header, and the fact that we wanted mail sent to people,
> not to a list of people.
> 
> If you can resolve the fact that you'd have to send email to classes of
> people (owner, all CC list, etc.), then it should be an acceptable
> optimization.
> 
> Later,
> Paul
> ------------------------------------------------------------------------
> J. Paul Reed -- 0xDF8708F8 || preed@... || web.sigkill.com/preed
> Math, my dear boy, is nothing more than the lesbian sister of biology.
>                                             -- Peter Griffin, Family Guy
> 
> I use PGP; you should use PGP too... if only to piss off John Ashcroft
> -
> To view or change your list settings, click here:
(Continue reading)

Gervase Markham | 1 Dec 2004 21:49
Picon
Favicon
Gravatar

Re: Patch query - single email per bug

J. Paul Reed wrote:
> If you can resolve the fact that you'd have to send email to classes of
> people (owner, all CC list, etc.), then it should be an acceptable
> optimization.

What about insidergroup? If a comment is marked as insidergroup, and 
other changes are made at the same time, half the CC list need one email 
and half need the other.

It might be possible to write a patch which works out all the possible 
parameters for an email, and amalgamates any which have exactly the same 
parameters - but there's a danger of it breaking every time email gets 
more customisable.

Gerv
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+jYtjvyW6yDsg <at> public.gmane.org>

David Miller | 1 Dec 2004 22:10
Gravatar

Re: Patch query - single email per bug

Kevin Benton wrote:
> Has anyone written a patch to make BZ send just one email per bug?  I
> have one here as a local customization.  It allows our mail servers to
> kill some of the duplicate emails that are going out (due to members of
> lists getting notified along with being included for other reasons). 
> It's also reducing the load on the server because it only makes one call
> to sendmail instead of one per recipient.  I'd like to include it in the
> public release.
> 
> Before I send it up for review, I wanted to get feedback on the idea
> first.  I plan to implement a flag to enable/disable this feature named
> OneEmailPerBug with a status of on/off.

Bugzilla used to do that, and it got killed on purpose when we allowed 
users to customize what events they get email for.  It was left that way 
after some discussion because users will soon be able to customize how 
their email is delivered (i.e. text vs html, etc) and the number of 
parameters affecting what the email each person should get are just 
snowballing.

--

-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+jYtjvyW6yDsg <at> public.gmane.org>

Kevin Benton | 1 Dec 2004 22:36
Picon
Favicon

Re: Patch query - single email per bug

Hi Gerv.

The way the patch works here is off the  <at> sentlist as built in
NewProcessOnePerson.  What was done was basically to take the call to
sendmail out of this routine, and then add a call to SendMail() near the
end of ProcessOneBug().

>From what I'm hearing you say, one bug can have a number of different
email output types.  My code doesn't currently account for that,
however, I can make an adjustment to cover that type of situation.

Here's how I would overcome that situation:  During the build of email
recipients, a list of recipients would be created with each unique email
to go out.  Uniqueness would be determined by getting an MD5sum of the
outbound text excluding the recipient list.  

When the MD5's match, the email recipient would just get added to the
existing recipient list.  If the outgoing text were unique, a new entry
in the hash would be created with the MD5 as the key.

AcutalRecipientList{md5hash}={'recipients'=>array(/*recipient emails*/),
                              'body'=>$bodystr /* message body */,
                              'subject'=>$subject /* message subject */}

Then, when SendMail() actually goes to sending the mail, it just steps
through the hash.

Of course, this could easily be done in a class.  As I see it, the
methodology I am thinking of would still remain the same.  :)

(Continue reading)

David Miller | 1 Dec 2004 22:42
Gravatar

Re: Patch query - single email per bug

Kevin Benton wrote:

> When the MD5's match, the email recipient would just get added to the
> existing recipient list.  If the outgoing text were unique, a new entry
> in the hash would be created with the MD5 as the key.

This kind of thing might work.  Another issue to be aware of is that a 
lot of mail servers have a limit to the allowed number of recipients on 
a single message (as an anti-spam measure).  I know Sendmail (which most 
of the net seems to be using still) defaults to a limit of 50 recipients 
per message.  Many ISPs limit it much smaller (like 15).

--

-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+jYtjvyW6yDsg <at> public.gmane.org>

Kevin Benton | 1 Dec 2004 22:54
Picon
Favicon

Re: Patch query - single email per bug

Good idea - adding a maximum_recipients_per_email parameter should take
care of that, right?  :)

On Wed, 2004-12-01 at 14:42, David Miller wrote:
> Kevin Benton wrote:
> 
> > When the MD5's match, the email recipient would just get added to the
> > existing recipient list.  If the outgoing text were unique, a new entry
> > in the hash would be created with the MD5 as the key.
> 
> This kind of thing might work.  Another issue to be aware of is that a 
> lot of mail servers have a limit to the allowed number of recipients on 
> a single message (as an anti-spam measure).  I know Sendmail (which most 
> of the net seems to be using still) defaults to a limit of 50 recipients 
> per message.  Many ISPs limit it much smaller (like 15).

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+jYtjvyW6yDsg <at> public.gmane.org>

Jason Pyeron | 2 Dec 2004 00:06
Picon

Re: Patch query - single email per bug

I think setting maximum_recipients_per_email=1 is safe.
Sorry, I have been dealing with lunacy all day. Te post office says that 
releasing a list of mail boxes would harm national security.

I don't think that "saving" on bandwidth is worth the risk of not 
receiving bug mail. But...

Can we concatenate some of the messages that get delivered to the in box?

I get many same bug messages in a row, just over a few seconds.

On 1 Dec 2004, Kevin Benton wrote:

> Good idea - adding a maximum_recipients_per_email parameter should take
> care of that, right?  :)
> 

--

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-                                                               -
- Jason Pyeron                      PD Inc. http://www.pdinc.us -
- Partner & Sr. Manager              #1 2739 Saint Paul Street  -
- +1 (410) 808-6646 (c)              Baltimore, Maryland 21218  -
-                                                               -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

This message is for the designated recipient only and may contain 
privileged, proprietary, or otherwise private information. If you 
have received it in error, purge the message from your system and 
notify the sender immediately.  Any other use of the email by you 
(Continue reading)

Lee Ivy | 2 Dec 2004 08:28

Clearing out old history on a bugzilla project

Hello,
We are working with a bugzilla database that has been in place for about 3 years. Due to some changes in our company's product strategy, the data from 2001 until aooroximately summer 2004 is of minimal interest to us, and in some cases it gets in the way. Unfortunately both the old & recent data use the same project name in bugzilla.
 
We have two questions:
  1. When I run the bug status history chart, the chart is dominated by the old un-interesting data and the recent 2004 data is squished far to the right. Can anyone point us to where we could find the historical data that feeds into these charts, and tell us how to safely delete the old counts so that our graphs are not skewed by them anymore?
  2. We are considering going one step farther and archiving all the old bugs themselves. Is there a relatively safe way to do this? Are there any caveats, pitfalls, reasons to think twice before plowing ahead, etc? (or is there a safer alternative such as moving all the old ones to a different project?)
Thanks
 
Lee Ivy
QA Architect
netZentry, Inc.
990 Commercial #100, Palo Alto CA
650-799-8620
 

Gmane