From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8506 invoked by alias); 13 Jan 2004 00:16:52 -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 8462 invoked from network); 13 Jan 2004 00:16:51 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 13 Jan 2004 00:16:51 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AgCEj-0002jU-2K for ; Mon, 12 Jan 2004 19:16:49 -0500 Date: Tue, 13 Jan 2004 00:16:00 -0000 From: Daniel Jacobowitz To: gcc@gcc.gnu.org Subject: Re: gcc 3.5 integration branch proposal Message-ID: <20040113001648.GA5201@nevyn.them.org> Mail-Followup-To: gcc@gcc.gnu.org References: <90200277-4301-11D8-BDBD-000A95B1F520@apple.com> <20040110002526.GA13568@disaster.jaj.com> <82D6F34E-4306-11D8-BDBD-000A95B1F520@apple.com> <20040110154129.GA28152@disaster.jaj.com> <1073935323.3458.42.camel@minax.codesourcery.com> <1073951351.3458.162.camel@minax.codesourcery.com> <20040113000554.GB599@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040113000554.GB599@nevyn.them.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-01/txt/msg00748.txt.bz2 On Mon, Jan 12, 2004 at 07:05:54PM -0500, Daniel Jacobowitz wrote: > "Same high quality"? I know you're aware of them, but you might want > to revisit the reasons that _no vendor_ I know of in several years has > shipped an FSF released compiler. Even Debian, which is chronically > short of the talented manpower required for compiler development, ships > fifteen hundred lines of GCC patches plus a bleeding edge 3.3-cvs > snapshot last I checked. The people with real budgets, like SuSE and > Red Hat, have orders of magnitude more changes. > > I suspect the primary users of the release tarballs are roll-your-own > developers (mainly either embedded or need-a-newer-C++) and large site > installations (universities, corporate, etc.) who have a stable > existing OS with an older compiler. > > Obviously we want higher quality releases. But now that CodeSourcery > is doing the exact same thing as all other vendors, I'm sure you can > see why it happens, and holding off releases isn't going to help > anything. My utterly unqualified instinct says that postponing the > release branch isn't going to help, since developers and vendors have > absolutely demonstrated their willingness to work outside of the trunk. That message came out a whole lot meaner than appropriate. I'd like to apologize to Mark. No one can dispute that we're doing a whole lot better than we were before, and the quality of GCC releases is improving. However, extending Stage 3 to meet quality goals is not the way to accomplish further improvement. Especially not when we had some high-profile problems with patches not getting reviewed at the end of Stage 2. I think we need to cut our losses and move on, and despite the defeatist tone of the first third of this sentence, I think that will still leave GCC 3.4 as an improvement. Speaking just for myself, watching var-tracking not get reviewed repeatedly was a really depressing experience, since the patch motivated me to finish GDB support for the new debugging information. It's going to be a real user-visible quality-of-experience improvement when it goes in. The longer Stage 3 drags on, the longer you have to use a SuSE (?) vendor compiler to get it. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer