From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13872 invoked by alias); 30 Aug 2004 05:09:11 -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 13856 invoked from network); 30 Aug 2004 05:09:10 -0000 Received: from unknown (HELO mail.codesourcery.com) (65.74.133.10) by sourceware.org with SMTP; 30 Aug 2004 05:09:10 -0000 Received: (qmail 9069 invoked from network); 30 Aug 2004 05:09:09 -0000 Received: from localhost (HELO ?192.168.0.105?) (mitchell@127.0.0.1) by mail.codesourcery.com with SMTP; 30 Aug 2004 05:09:09 -0000 Message-ID: <4132B677.1020507@codesourcery.com> Date: Mon, 30 Aug 2004 06:57: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> <4132A903.6050303@codesourcery.com> <4132AE25.2080900@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/msg01456.txt.bz2 Gabriel Dos Reis wrote: >Mark Mitchell writes: > >| Gabriel Dos Reis wrote: >| >| >Mark Mitchell writes: >| > >| >| 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 >| > >| >That says a lot. >| > >| Note that I didn't say "cooperation"; I said "consensus", which means >| that everyone agrees. > >No. "everyone agrees" means "unanimity", and I consciously avoided >that term. > > Well, since I didn't know what the word meant, then you shouldn't read too much into what I said. :-) But I do think that our key stakeholders have very divergent objectives. At the GCC summit, one person I respect told me we should do releases every two weeks; another I respect equally much recommended once a year. I try to balance all the opinions to come up with a reasonable plan; to me, that's the "M" in "RM". Unless the SC tells me otherwise, of course. -- Mark Mitchell CodeSourcery, LLC (916) 791-8304 mark@codesourcery.com