From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7990 invoked by alias); 30 Aug 2004 03:55:55 -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 7980 invoked from network); 30 Aug 2004 03:55:53 -0000 Received: from unknown (HELO uniton.integrable-solutions.net) (62.212.99.186) by sourceware.org with SMTP; 30 Aug 2004 03:55:53 -0000 Received: from uniton.integrable-solutions.net (localhost [127.0.0.1]) by uniton.integrable-solutions.net (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id i7U3sBbR010266; Mon, 30 Aug 2004 05:54:11 +0200 Received: (from gdr@localhost) by uniton.integrable-solutions.net (8.12.3/8.12.3/Submit) id i7U3sAUD010265; Mon, 30 Aug 2004 05:54:10 +0200 X-Authentication-Warning: uniton.integrable-solutions.net: gdr set sender to gdr@integrable-solutions.net using -f To: Mark Mitchell 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> From: Gabriel Dos Reis In-Reply-To: <41329FC3.1000406@codesourcery.com> Organization: Integrable Solutions Date: Mon, 30 Aug 2004 04:17:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-08/txt/msg01450.txt.bz2 Mark Mitchell writes: [...] | >What are our release criteria? Sorry to ask the trivial, but it is | >because I'm unclear about what we're after. | > | There is no single answer. The GNU/Linux distro vendors want things, | embedded people want things, hardware vendors what things, and other | people want things. And, everyone wants the release schedule to line | up with their own personal and/or organizational schedules. | | As the RM, I want releases that are both timely and of high-quality. | These two things cannot be entirely traded against each other: longer | release cycles do not necessarily lead to higher quality. In fact, If you're saying that having a release cycle of ten years is not automatically going make the release of good quality, I can only agree with you. 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 that question is harder than the previous to answer because we don't seem to have metrics that throw numbers at us. I don't think we have answers for time and quality combined; or at least I'm just unable to find where we're consistently applying them. | 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. | I think that GCC 3.5 is going to be a good release. I also think that | the first release with major new technology (tree-ssa is easily the | biggest change to GCC in a decade) is going to have dot-zero | properties: it won't work perfectly for all people all of the time. | Since everyone else (including Oracle, Microsoft, Red Hat, etc.) has | that problem with huge revisions, I think we will have problems too -- | independently of exactly when we do a release. Oh, well. The issue is not whether we're going to have dot zero problems or not. But what is knowingly and with consensus decided to be included in that set. I'm not trying to make your job harder -- the RM position is alrady hard enough. -- Gaby