From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15113 invoked by alias); 30 Aug 2004 04:11:48 -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 15104 invoked from network); 30 Aug 2004 04:11:47 -0000 Received: from unknown (HELO mail.codesourcery.com) (65.74.133.10) by sourceware.org with SMTP; 30 Aug 2004 04:11:47 -0000 Received: (qmail 29105 invoked from network); 30 Aug 2004 04:11:45 -0000 Received: from localhost (HELO ?192.168.0.105?) (mitchell@127.0.0.1) by mail.codesourcery.com with SMTP; 30 Aug 2004 04:11:45 -0000 Message-ID: <4132A903.6050303@codesourcery.com> Date: Mon, 30 Aug 2004 04:43:00 -0000 From: Mark Mitchell Organization: CodeSourcery, LLC User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 MIME-Version: 1.0 To: Gabriel Dos Reis CC: Giovanni Bajo , gcc@gcc.gnu.org Subject: Re: GCC 3.5 Status (2004-08-29) References: <4132641E.3030206@codesourcery.com> <200408300148.54421.stevenb@suse.de> <41326EBF.9020501@codesourcery.com> <200408300229.13652.stevenb@suse.de> <41327A88.5080903@codesourcery.com> <023b01c48e35$0f5ef9f0$8f432597@bagio> <41329FC3.1000406@codesourcery.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-08/txt/msg01452.txt.bz2 Gabriel Dos Reis wrote: >Making regular bug-fix releases at regularly spaced times makes good >sense to me. What I'm unclear about is what we want for the *major* >releases. Do we just want them every 6 months? Do we drive it by >quality? If by quality, what are the quality criteria? I suspect > > We cannot drive it purely by quality, since we will never get quality unless we decide that we're going to make a release. The level of bug-fixing activity goes up steeply as we approach a release: people start to fear that "their" platform/language/etc. will not work well. That's why we use a combination: drive by time, and then push for quality towards that date. >| they can lead to lower quality, as more and more changes go in, >| sometimes without corresponding problem-solving efforts. I also don't >| think that "wait until it is ready" is a practical method for a >| project this big with this much change and with so much >| inter-dependency between components. > >Again, I agree. However, because the project is that big, I believe >branching proposals should meet consensus among developers. > > In contrast, I don't see consensus as achievable in this group. We barely get consensus on technical issues, let alone on priorities. Instead, I see my job as to take input, ponder it, consult with people, and make decisions. The decisions I made about 3.5 were made with lots of input from lots of people -- developers, users, and other stakeholders -- and informed by discussions with people going back as far as the summit in Ottawa. I don't expect everyone to be 100% happy about my decisions; I only hope to do a good enough job of being fair and reasonable that people respect them. -- Mark Mitchell CodeSourcery, LLC (916) 791-8304 mark@codesourcery.com