From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4023 invoked by alias); 26 Oct 2007 16:08:00 -0000 Received: (qmail 4014 invoked by uid 22791); 26 Oct 2007 16:07:59 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 26 Oct 2007 16:07:56 +0000 Received: (qmail 21757 invoked from network); 26 Oct 2007 16:07:54 -0000 Received: from unknown (HELO ?192.168.0.3?) (mitchell@127.0.0.2) by mail.codesourcery.com with ESMTPA; 26 Oct 2007 16:07:54 -0000 Message-ID: <472210D7.1090902@codesourcery.com> Date: Fri, 26 Oct 2007 16:08:00 -0000 From: Mark Mitchell User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Andrew MacLeod CC: Richard Guenther , GCC Subject: Re: GCC 4.3 release schedule References: <4721E663.1080405@redhat.com> <84fc9c000710260645m29398c4fn854c067fe42c6ddc@mail.gmail.com> <4721FB6C.8030506@redhat.com> In-Reply-To: <4721FB6C.8030506@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg00492.txt.bz2 Andrew MacLeod wrote: > we can at least make projected dates known so we have something firmer > than "at some point in the future" :-) The canonical rule of project management is: "Features, Schedule, Cost: Pick At Most 2." :-) In other words, you can decide what features you want and when you want them by -- but be prepared to pay for a vast team. Or, you can decide what you want to pay, and when you want it -- but be prepared to get whatever features are done by then with the team you paid for. In the case of GCC, it's worse than that since we're not all interested in the same things, or being in any way centrally directed. As RM, I try to take into account what I know about when distributors will be applying effort, but I must absolutely avoid in any way tilting the FSF release process towards the needs of one distributor, possibly at the expense of another. I don't think it's appropriate for us to set a schedule tailored to any one distributor's needs -- and there are a lot more distributors than just Red Hat and SuSE, so I'd say that even if you were on the same schedule. But, I certainly do think it's helpful for a contributor to tell us when resources might be available and I appreciate you sharing that information. If you're interested in driving the release to a particular date, the best thing you can do is to go clear out the P1s in bugzilla and then bash out a few P2s. (I've noticed Red Hat folks doing some of that already, thanks!) I'd imagine that the dates you want to hit would be achievable if you, Jakub, Jason, etc. all work on issues. 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. Thanks, -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713