From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19152 invoked by alias); 31 Jan 2003 16:51:58 -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 19140 invoked from network); 31 Jan 2003 16:51:57 -0000 Received: from unknown (HELO localhost.localdomain) (66.60.148.227) by 172.16.49.205 with SMTP; 31 Jan 2003 16:51:57 -0000 Received: from warlock.codesourcery.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id h0VGmAC01855; Fri, 31 Jan 2003 08:48:11 -0800 Date: Fri, 31 Jan 2003 18:02:00 -0000 From: Mark Mitchell To: "Joseph S. Myers" , Benjamin Kosnik cc: "gcc@gcc.gnu.org" Subject: Re: GCC 3.3, GCC 3.4 Message-ID: <48900000.1044031690@warlock.codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SW-Source: 2003-01/txt/msg01776.txt.bz2 --On Friday, January 31, 2003 11:03:41 AM +0000 "Joseph S. Myers" wrote: > On Thu, 30 Jan 2003, Benjamin Kosnik wrote: > >> I think the longer gcc, as a project, goes on without an autobuild >> continuous regression checker, the worse off things will get. I've caught up now on this entire thread, and I spent about an hour talking to Benjamin last night. I appreciate the time he took to talk to me and the input he provided, including some practical notes about when Red Hat people would be more likely to help and when they wouldn't. If people have concerns about how I'm doing my job, I want to hear them. My job as RM is to serve the FSF's interests -- not CodeSourcery's, or anyone elses. It's a little unclear what the FSF's interests *are*, other than the overall success of free software, but I've got to assume that they include the widespread usage of GCC and the avoidance of forks, which, to me, implies reasonably high-quality releases reasonably often. I find it a very hard balancing act. Do releases often, and you're always working on fixing regressions, testing, packaging, etc. Do releases rarely and the bugs get so bad it's incredibly hard to fix them all. Do them on a major GNU/Linux vendor's release schedule and you get more help from those vendors, but maybe not at a time that's terribly natural for the pace of other development. Decide that there have been enough major changes for one release, and you risk irritating the people who have been working on the branch that didn't get in. Take the code anyhow and you risk introducing more bugs and exposing users to immature technology. You get the picture. :-) I completely agree that more automated testing, and non-automated testing, would be extremely helpful. I also agree that more bug-fixing would be good; right now we *know* about a lot of regressions -- but we don't have fixes for most of them. Architecture cleanups that make it harder to introduce bugs also help a lot. Nobody seems to be objecting particularly much to the idea of leaving stage 1 for GCC 3.4 on March 15th. So, let's make that firm. We've already got two major pieces of new technology: a new C++ parser, and PCH support. There are still serious bugs in both, no doubt, but we're making good progress. I think if we get another branch merged in, we'll have enough bugs to keep us busy forever. As for GCC 3.3, I guess we'd better play it a bit by ear. It doesn't appear that most people think we can make March 1. I'm going to keep that as my own internal target, so that I have something to motivate me to fix a bug or two on a Saturday night, but we'll not be too firm about it. Thanks to all of you for commenting. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com