From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29045 invoked by alias); 14 Apr 2002 22:29: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 29036 invoked from network); 14 Apr 2002 22:29:55 -0000 Received: from unknown (HELO igw3.watson.ibm.com) (198.81.209.18) by sources.redhat.com with SMTP; 14 Apr 2002 22:29:55 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g3EMQVQ08222; Sun, 14 Apr 2002 18:26:31 -0400 Received: from makai.watson.ibm.com (makai.watson.ibm.com [9.2.216.144]) by sp1n293en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g3EMQVM37526; Sun, 14 Apr 2002 18:26:31 -0400 Received: from watson.ibm.com (localhost [127.0.0.1]) by makai.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) with ESMTP id SAA25484; Sun, 14 Apr 2002 18:26:31 -0400 Message-Id: <200204142226.SAA25484@makai.watson.ibm.com> To: Bryce McKinlay cc: Toon Moene , Neil Booth , Mark Mitchell , gcc@gcc.gnu.org Subject: Re: GCC 3.1 Release In-Reply-To: Message from Bryce McKinlay of "Sun, 14 Apr 2002 17:33:49 +1200." <3CB914BD.4080007@waitaki.otago.ac.nz> Date: Sun, 14 Apr 2002 17:04:00 -0000 From: David Edelsohn X-SW-Source: 2002-04/txt/msg00574.txt.bz2 >>>>> Bryce McKinlay writes: Bryce> One could argue that the long cycle between 3.0 and 3.1 is partly Bryce> responsible for the 3.1 release problems, by allowing a longer period Bryce> for bugs to creep in before developer focus shifted to fixing them. I Bryce> think we should try for at least one release on the shorter cycle, with Bryce> an option to re-evaluate its effectiveness as the 3.2 release approaches Bryce> or after it is made. One can arbitrarily divide the bugs into two categories: regressions with testcases in the "torture" suite and regressions reported through Gnats. For the former, we all need to do better to fix regressions as they occur. For the latter, we sometimes do not get immediate feedback about the failures or the failures are latent bugs not directly caused by a change. Regressions and bugs are a byproduct of invasive changes to the compiler. If we are not creating and/or exposing bugs, we probably are not improving the compiler substantially. Bryce> Perhaps we could go by a stable/unstable release cycle, similar to Bryce> Linux. Unstable releases would follow a shorter period of Bryce> stabilization/freezing/testing/branching than is done for a full, stable Bryce> release. This would give users wanting to test and play with new Bryce> features something which is known to be better tested than the average Bryce> snapshot, but without the pain and major disruption to development that Bryce> full releases seem to require. We are working on many different areas of the compiler simultaneously. Clearly new languages (such as Java and GCJ) would like to have the rest of the compiler remain stable while it rapidly pushes forward with more complete language support and ports to more platforms. Other users want to see optimization improvements for existing languages. Another community wants greater standards conformance for existing languages. It is hard to strike the right balance. We need an open, inclusive, constructive discussion to navigate a reasonable course. I conducted a survey about the GCC release schedule. *NONE* of the companies (Linux distributors, free software and open source projects, embedded systems companies) wanted a release on a six month cycle. No one wants to have to transition and re-validate their software and repackage a new distribution with great frequency. Nine to twelve months is the soonest that bulk end-users who create the dependence on GCC versions want to be burdened with updating. If we want to remain on a six month cycle, alternating between "technology preview" releases and "production" releases (e.g., GCC 3.0 and GCC 3.1) would be a good plan, IMHO. For that type of approach to work, I think that we need to make every effort to ensure that radical, invasive changes are merged into the mainline for even numbered releases so that odd numbered releases are not substantially destabilized and developers do not need to wait 18 months for their contributions to be accepted. We have a lot of good technology ready on branches and being offered by developers that we need to figure out how to merge into the trunk for GCC 3.2. Thanks, David