A few suggestions for bugzilla mail to gcc-bugs

A few suggestions for bugzilla mail to gcc-bugs

[Segher Boessenkool]

Hi,

A few suggestions for the mail to gcc-bugs, taking this recent
message as an example:

 > PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

Can't this be automated?

 > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10942

Maybe show the short URL here?

 > ------- Additional Comments From edmar@motorola.com  2003-05-22 17:30 -------
 > Created an attachment (id=4054)
 >  --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=4054&action=view)
 > Preprocessed file that caused the ICE

Although I really like not getting any useless 500kB+ emails
through gcc-bugs anymore, if an attachment is short, can it
be sent in the actual email please?

 > ------- You are receiving this mail because: -------
 > You are on the CC list for the bug, or are watching someone who is.

Can this line be removed?

All this (except the attachment thing, maybe) applies to the messages
to gcc-bugs only, not messages to "normal" users.

Thanks for considering,


Segher

Re: A few suggestions for bugzilla mail to gcc-bugs

[Daniel Berlin]

On Sat, 24 May 2003, Segher Boessenkool wrote:

> Hi,
>
> A few suggestions for the mail to gcc-bugs, taking this recent
> message as an example:
>
>  > PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
>
> Can't this be automated?
Actually, it can't, AFAIK.

>
>  > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10942
>
> Maybe show the short URL here?
Sure, i guess.


>
>  > ------- Additional Comments From edmar@motorola.com  2003-05-22 17:30 -------
>  > Created an attachment (id=4054)
>  >  --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=4054&action=view)
>  > Preprocessed file that caused the ICE
>
> Although I really like not getting any useless 500kB+ emails
> through gcc-bugs anymore, if an attachment is short, can it
> be sent in the actual email please?

Define short.

>
>  > ------- You are receiving this mail because: -------
>  > You are on the CC list for the bug, or are watching someone who is.
>
> Can this line be removed?

Possibly, let me look into it.

>
> All this (except the attachment thing, maybe) applies to the messages
> to gcc-bugs only, not messages to "normal" users.
>
> Thanks for considering,
>
>
> Segher
>
>
>

Re: A few suggestions for bugzilla mail to gcc-bugs

[Daniel Jacobowitz]

On Fri, May 23, 2003 at 10:02:36PM -0400, Daniel Berlin wrote:
> 
> 
> On Sat, 24 May 2003, Segher Boessenkool wrote:
> 
> > Hi,
> >
> > A few suggestions for the mail to gcc-bugs, taking this recent
> > message as an example:
> >
> >  > PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
> >
> > Can't this be automated?
> Actually, it can't, AFAIK.

Well, there's already a Reply-To: header set...

> >  > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10942
> >
> > Maybe show the short URL here?
> Sure, i guess.
> 
> 
> >
> >  > ------- Additional Comments From edmar@motorola.com  2003-05-22 17:30 -------
> >  > Created an attachment (id=4054)
> >  >  --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=4054&action=view)
> >  > Preprocessed file that caused the ICE
> >
> > Although I really like not getting any useless 500kB+ emails
> > through gcc-bugs anymore, if an attachment is short, can it
> > be sent in the actual email please?
> 
> Define short.

Let's just pick a reasonable limit - how about 20K?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: A few suggestions for bugzilla mail to gcc-bugs

[Daniel Berlin]

On Friday, May 23, 2003, at 10:23  PM, Daniel Jacobowitz wrote:

> On Fri, May 23, 2003 at 10:02:36PM -0400, Daniel Berlin wrote:
>>
>>
>> On Sat, 24 May 2003, Segher Boessenkool wrote:
>>
>>> Hi,
>>>
>>> A few suggestions for the mail to gcc-bugs, taking this recent
>>> message as an example:
>>>
>>>> PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* 
>>>> gcc-bugs@gcc.gnu.org.
>>>
>>> Can't this be automated?
>> Actually, it can't, AFAIK.
>
> Well, there's already a Reply-To: header set...
>>
Yes, but i can't automate people doing the right thing.
I can, however, remove the banner, and already planned on it.

>>>
>>>> ------- Additional Comments From edmar@motorola.com  2003-05-22 
>>>> 17:30 -------
>>>> Created an attachment (id=4054)
>>>>  --> 
>>>> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=4054&action=view)
>>>> Preprocessed file that caused the ICE
>>>
>>> Although I really like not getting any useless 500kB+ emails
>>> through gcc-bugs anymore, if an attachment is short, can it
>>> be sent in the actual email please?
>>
>> Define short.
>
> Let's just pick a reasonable limit - how about 20K?

Actually, let's not do it.
It's not easy to do, it's cpu consuming (attachments are stored 
compressed in the db, so i'd have to uncompress the attachments every 
time we go to send out mail, just to see if they are the right size) 
first, and second, it's a security risk (auto-distribute hacks by 
posting them as an attachment).

Re: A few suggestions for bugzilla mail to gcc-bugs

[DJ Delorie]

> Yes, but i can't automate people doing the right thing.

How about a procmail rule?  If gcc-bugs gets mail and sees
To:.*gcc-bugzilla in the headers, it silently discards the email.

Assuming gcc-bugs uses procmail, of course.

Re: A few suggestions for bugzilla mail to gcc-bugs

[Segher Boessenkool]

Daniel Jacobowitz wrote:
> Well, there's already a Reply-To: header set...

Yes, but reply-to-all replies to the To: address as well,
and that's what I normally hit (unless I'm thinking ;) );
I don't think I'm the only one doing that...

>>Define short.
> 
> Let's just pick a reasonable limit - how about 20K?

Fine with me...


Segher

Re: A few suggestions for bugzilla mail to gcc-bugs

[Daniel Berlin]

On Friday, May 23, 2003, at 11:05  PM, DJ Delorie wrote:

>
>> Yes, but i can't automate people doing the right thing.
>
> How about a procmail rule?

Funny you mention, when i sugggested a procmail rule to chris for 
handling mail to gcc-gnats, so that i didn't have to handle it in the 
script, he said handling it in the script would be much easier than 
trying to get qmail to run procmail and do this, etc.

>  If gcc-bugs gets mail and sees
> To:.*gcc-bugzilla in the headers, it silently discards the email.
>
> Assuming gcc-bugs uses procmail, of course.
>

It doesn't, it uses qmail + something else.

--Dan

Re: A few suggestions for bugzilla mail to gcc-bugs

[Joseph S. Myers]

On Fri, 23 May 2003, Daniel Berlin wrote:

> >  > PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
> >
> > Can't this be automated?
> Actually, it can't, AFAIK.

Automating it involves:

* Teaching the spam-checking on gcc-bugs that gcc-bugzilla is another name 
for that list, so it can accept mails with just gcc-bugzilla in the 
destination headers.  (As it presently accepts mails for bug-gcc@gnu.org.)

* Having Bugzilla put gcc-bugzilla in the To: header (as well as the From:  
header) but really send the messages to gcc-bugs instead (as the headers
and where the message really goes are entirely independent).  So the
headers from which a mail reader might take addresses to reply to wouldn't
mention gcc-bugs at all.  But this might not be something Bugzilla is
designed to make easy to do.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: A few suggestions for bugzilla mail to gcc-bugs

[Daniel Jacobowitz]

On Fri, May 23, 2003 at 10:56:36PM -0400, Daniel Berlin wrote:
> 
> On Friday, May 23, 2003, at 10:23  PM, Daniel Jacobowitz wrote:
> 
> >On Fri, May 23, 2003 at 10:02:36PM -0400, Daniel Berlin wrote:
> >>
> >>
> >>On Sat, 24 May 2003, Segher Boessenkool wrote:
> >>
> >>>Hi,
> >>>
> >>>A few suggestions for the mail to gcc-bugs, taking this recent
> >>>message as an example:
> >>>
> >>>>PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* 
> >>>>gcc-bugs@gcc.gnu.org.
> >>>
> >>>Can't this be automated?
> >>Actually, it can't, AFAIK.
> >
> >Well, there's already a Reply-To: header set...
> >>
> Yes, but i can't automate people doing the right thing.
> I can, however, remove the banner, and already planned on it.
> 
> >>>
> >>>>------- Additional Comments From edmar@motorola.com  2003-05-22 
> >>>>17:30 -------
> >>>>Created an attachment (id=4054)
> >>>> --> 
> >>>>(http://gcc.gnu.org/bugzilla/attachment.cgi?id=4054&action=view)
> >>>>Preprocessed file that caused the ICE
> >>>
> >>>Although I really like not getting any useless 500kB+ emails
> >>>through gcc-bugs anymore, if an attachment is short, can it
> >>>be sent in the actual email please?
> >>
> >>Define short.
> >
> >Let's just pick a reasonable limit - how about 20K?
> 
> Actually, let's not do it.
> It's not easy to do, it's cpu consuming (attachments are stored 
> compressed in the db, so i'd have to uncompress the attachments every 
> time we go to send out mail, just to see if they are the right size) 
> first, and second, it's a security risk (auto-distribute hacks by 
> posting them as an attachment).

Can you query the compressed size more quickly?  We don't need to be
precise here...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: A few suggestions for bugzilla mail to gcc-bugs

[Daniel Berlin]

On Saturday, May 24, 2003, at 05:27  AM, Joseph S. Myers wrote:

> On Fri, 23 May 2003, Daniel Berlin wrote:
>
>>>> PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* 
>>>> gcc-bugs@gcc.gnu.org.
>>>
>>> Can't this be automated?
>> Actually, it can't, AFAIK.
>
> Automating it involves:
>
> * Teaching the spam-checking on gcc-bugs that gcc-bugzilla is another 
> name
> for that list, so it can accept mails with just gcc-bugzilla in the
> destination headers.  (As it presently accepts mails for 
> bug-gcc@gnu.org.)
>
> * Having Bugzilla put gcc-bugzilla in the To: header (as well as the 
> From:
> header) but really send the messages to gcc-bugs instead (as the 
> headers
> and where the message really goes are entirely independent).  So the
> headers from which a mail reader might take addresses to reply to 
> wouldn't
> mention gcc-bugs at all.  But this might not be something Bugzilla is
> designed to make easy to do.
Bugzilla simply generates the entire message (once for each person to 
receive mail about a bug, since each person has different email 
preferences)  and hands it off to sendmail (really qmail's sendmail 
emulator).

If you know how to do it given these parameters, i'm happy to do it.

Re: A few suggestions for bugzilla mail to gcc-bugs

[Joseph S. Myers]

On Sat, 24 May 2003, Daniel Berlin wrote:

> Bugzilla simply generates the entire message (once for each person to 
> receive mail about a bug, since each person has different email 
> preferences)  and hands it off to sendmail (really qmail's sendmail 
> emulator).
> 
> If you know how to do it given these parameters, i'm happy to do it.

You need to pass the real destination email address (i.e. gcc-bugs) on the
sendmail command line, rather than using sendmail options to extract email
addresses from the headers.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: A few suggestions for bugzilla mail to gcc-bugs

[Andreas Schwab]

Daniel Jacobowitz <drow@mvista.com> writes:

|> Can you query the compressed size more quickly?  We don't need to be
|> precise here...

"gzip -l" should do the trick, provided that the input is seekable.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: A few suggestions for bugzilla mail to gcc-bugs

[Daniel Berlin]

On Mon, 2 Jun 2003, Andreas Schwab wrote:

> Daniel Jacobowitz <drow@mvista.com> writes:
>
> |> Can you query the compressed size more quickly?  We don't need to be
> |> precise here...
>
> "gzip -l" should do the trick, provided that the input is seekable.
This isn't shell script, it's perl, forking a new process in a very often
used cgi script for every single attachment is *not* a good idea.

But that's besides the point anyway.
The data is *not* in gzip format in memory.
It has no gzip header with the size in it in front.

The *only* way to get the size is to decompress it.
I could, of course, convert them all to be in-memory gzip files, but i'm a
bit busy with other things at the moment to care about this.
:)

Re: A few suggestions for bugzilla mail to gcc-bugs

[Daniel Jacobowitz]

On Mon, Jun 02, 2003 at 05:33:15PM -0400, Daniel Berlin wrote:
> 
> 
> On Mon, 2 Jun 2003, Andreas Schwab wrote:
> 
> > Daniel Jacobowitz <drow@mvista.com> writes:
> >
> > |> Can you query the compressed size more quickly?  We don't need to be
> > |> precise here...
> >
> > "gzip -l" should do the trick, provided that the input is seekable.
> This isn't shell script, it's perl, forking a new process in a very often
> used cgi script for every single attachment is *not* a good idea.
> 
> But that's besides the point anyway.
> The data is *not* in gzip format in memory.
> It has no gzip header with the size in it in front.
> 
> The *only* way to get the size is to decompress it.
> I could, of course, convert them all to be in-memory gzip files, but i'm a
> bit busy with other things at the moment to care about this.
> :)

I still think we should have some way to get at the compressed size. 
But I assume it's in the DB somewhere and databases were never my
strong point.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: A few suggestions for bugzilla mail to gcc-bugs

[Daniel Berlin]

On Mon, 2 Jun 2003, Daniel Jacobowitz wrote:

> On Mon, Jun 02, 2003 at 05:33:15PM -0400, Daniel Berlin wrote:
> >
> >
> > On Mon, 2 Jun 2003, Andreas Schwab wrote:
> >
> > > Daniel Jacobowitz <drow@mvista.com> writes:
> > >
> > > |> Can you query the compressed size more quickly?  We don't need to be
> > > |> precise here...
> > >
> > > "gzip -l" should do the trick, provided that the input is seekable.
> > This isn't shell script, it's perl, forking a new process in a very often
> > used cgi script for every single attachment is *not* a good idea.
> >
> > But that's besides the point anyway.
> > The data is *not* in gzip format in memory.
> > It has no gzip header with the size in it in front.
> >
> > The *only* way to get the size is to decompress it.
> > I could, of course, convert them all to be in-memory gzip files, but i'm a
> > bit busy with other things at the moment to care about this.
> > :)
>
> I still think we should have some way to get at the compressed size.
> But I assume it's in the DB somewhere and databases were never my
> strong point.

Yes, that's trivial.
But the compressed size is sometimes very far off, and it would trick
people into thinking it was going to take 10x less size than it does.

I picked a random C++ preprocessed file:

800k uncompressed,
89k compressed

that's like 9:1.

>
> --
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer
>

Re: A few suggestions for bugzilla mail to gcc-bugs

[Daniel Jacobowitz]

On Mon, Jun 02, 2003 at 05:50:03PM -0400, Daniel Berlin wrote:
> 
> 
> On Mon, 2 Jun 2003, Daniel Jacobowitz wrote:
> 
> > On Mon, Jun 02, 2003 at 05:33:15PM -0400, Daniel Berlin wrote:
> > >
> > >
> > > On Mon, 2 Jun 2003, Andreas Schwab wrote:
> > >
> > > > Daniel Jacobowitz <drow@mvista.com> writes:
> > > >
> > > > |> Can you query the compressed size more quickly?  We don't need to be
> > > > |> precise here...
> > > >
> > > > "gzip -l" should do the trick, provided that the input is seekable.
> > > This isn't shell script, it's perl, forking a new process in a very often
> > > used cgi script for every single attachment is *not* a good idea.
> > >
> > > But that's besides the point anyway.
> > > The data is *not* in gzip format in memory.
> > > It has no gzip header with the size in it in front.
> > >
> > > The *only* way to get the size is to decompress it.
> > > I could, of course, convert them all to be in-memory gzip files, but i'm a
> > > bit busy with other things at the moment to care about this.
> > > :)
> >
> > I still think we should have some way to get at the compressed size.
> > But I assume it's in the DB somewhere and databases were never my
> > strong point.
> 
> Yes, that's trivial.
> But the compressed size is sometimes very far off, and it would trick
> people into thinking it was going to take 10x less size than it does.
> 
> I picked a random C++ preprocessed file:
> 
> 800k uncompressed,
> 89k compressed
> 
> that's like 9:1.

Like I said, not shooting for accuracy here :)  Anything that
compresses down to 5K, say.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer