From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32727 invoked by alias); 24 May 2003 02:56:47 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 32720 invoked from network); 24 May 2003 02:56:47 -0000 Received: from unknown (HELO dberlin.org) (69.3.5.6) by sources.redhat.com with SMTP; 24 May 2003 02:56:47 -0000 Received: from [192.168.1.3] (account dberlin HELO dberlin.org) by dberlin.org (CommuniGate Pro SMTP 4.1b6) with ESMTP-TLS id 4059740; Fri, 23 May 2003 22:56:40 -0400 Date: Sat, 24 May 2003 03:05:00 -0000 Subject: Re: A few suggestions for bugzilla mail to gcc-bugs Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Segher Boessenkool , gcc To: Daniel Jacobowitz From: Daniel Berlin In-Reply-To: <20030524022356.GA7386@nevyn.them.org> Message-Id: <557D9182-8D93-11D7-AC8F-000A95A34564@dberlin.org> Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg02171.txt.bz2 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).