From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13111 invoked by alias); 13 Jan 2004 23:13:46 -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 13097 invoked from network); 13 Jan 2004 23:13:44 -0000 Received: from unknown (HELO dberlin.org) (69.3.5.6) by sources.redhat.com with SMTP; 13 Jan 2004 23:13:44 -0000 Received: from [128.164.132.32] (account dberlin HELO [192.168.170.251]) by dberlin.org (CommuniGate Pro SMTP 4.1.4) with ESMTP-TLS id 5863862; Tue, 13 Jan 2004 18:13:43 -0500 In-Reply-To: <200401132241.i0DMfbT28126@makai.watson.ibm.com> References: <200401132241.i0DMfbT28126@makai.watson.ibm.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <202ADE61-461E-11D8-8072-000A95DA505C@dberlin.org> Content-Transfer-Encoding: 7bit Cc: Geoff Keating , Mark Mitchell , gcc@gcc.gnu.org From: Daniel Berlin Subject: Re: gcc 3.5 integration branch proposal Date: Tue, 13 Jan 2004 23:13:00 -0000 To: David Edelsohn X-SW-Source: 2004-01/txt/msg00828.txt.bz2 > FSF GCC also has a very large and diverse user community who > provide conflicting feedback about their priorities: One way of gauging their feedback is to turn on the voting system in Bugzilla. Since we have bugs for all of these things in Bugzilla, people can vote for the bugs that are most commiserate with their goals. Of course, like all things, this is subject to it's own set of problems. But right now, the only gauge we get is the mailing lists, and people's general feelings reviewing bug reports, neither of which is really quantifiable into a hard number we can look at :). Of course, we could always turn it back off it it just seems to be a nuisance. > > * Correct code generation > * Fewer ICEs > * Standards conformance > * Compilation speed > * Performance > * Features > * Release frequency > * Release timeliness > > We need to figure out how to balance those goals better without > losing ground in areas where we recently have been improving. > Some of the problem is that we have people maintaining *large* numbers of areas of the compiler, but not fixing regressions (hopefully non-controversial) or improving code speed (this may be more controversial) in those areas. That is, after all, part of being a maintainer. It's not just an honorary title. We need more people assigned (not more assignments for existing people) to various areas of the compiler, who *want* to be fixing regressions and improving speed in various areas of the compiler. And anyone who tries to argue we don't have the manpower to do this, is simply kidding themselves. These people certainly exist, and are, on this mailing list. --Dan