From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13637 invoked by alias); 26 Oct 2007 16:18:45 -0000 Received: (qmail 13628 invoked by uid 22791); 26 Oct 2007 16:18:45 -0000 X-Spam-Check-By: sourceware.org Received: from py-out-1112.google.com (HELO py-out-1112.google.com) (64.233.166.182) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 26 Oct 2007 16:18:39 +0000 Received: by py-out-1112.google.com with SMTP id a29so1696649pyi for ; Fri, 26 Oct 2007 09:18:37 -0700 (PDT) Received: by 10.65.107.10 with SMTP id j10mr6778545qbm.1193415514614; Fri, 26 Oct 2007 09:18:34 -0700 (PDT) Received: by 10.65.232.20 with HTTP; Fri, 26 Oct 2007 09:18:34 -0700 (PDT) Message-ID: <84fc9c000710260918m508ff82rf2033c007b0a8d5c@mail.gmail.com> Date: Fri, 26 Oct 2007 16:21:00 -0000 From: "Richard Guenther" To: "Mark Mitchell" Subject: Re: GCC 4.3 release schedule Cc: "Andrew MacLeod" , GCC In-Reply-To: <472210D7.1090902@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4721E663.1080405@redhat.com> <84fc9c000710260645m29398c4fn854c067fe42c6ddc@mail.gmail.com> <4721FB6C.8030506@redhat.com> <472210D7.1090902@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2007-10/txt/msg00496.txt.bz2 On 10/26/07, Mark Mitchell wrote: > > I've found schedules for GCC to be very hard to predict. As I said in > my status report, our practice has been to cut the release branch when > we reach 100 regressions, and release 2-4 months after that point, > depending on quality on the branch. To be honest, I'd rather wait > longer to make the branch -- but there tends to be intense pressure in > the developer community to make a branch so we can get on to the next > round of major features. In any case, after we make the branch, it's in > regression-only mode, so stability tends to be quite good, though > dot-zero releases are, after all, dot-zero releases. To jump in on the last fact - dot-zero releases are dot-zero releases - it makes sense to expose the branch to wider testing by, at branching time, exposing a dot-zero release to the public ;) And I seriously dispute that branching and waiting has ever made the branch of better quality just because we branched and waited. Instead the opposite is true - developer ressources are dragged away to work on their stage1 projects (that is true for myself). I'd rather take the make the dot-zero release approach while branching and count on interested people fixing bugs on the branch after the dot-zero release. This way if nobody is interested on a particular release series then we can declare the dot-zero release final - otherwise we'd do more releases from the branch anyway. Which still leaves us with the problem of setting criteria for releasing a dot-zero. Being it 100 regressions or zero P1 bugs or whatever. Early testing certainly helps here (sofar we are doing build-testing only, but I expect to put the built binaries in "production" soon), but there are still serious problems with 4.3 at the moment, like sorting out the libstdc++ API mess. Thanks, Richard.