From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6136 invoked by alias); 20 Jan 2004 01:39:57 -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 6113 invoked from network); 20 Jan 2004 01:39:56 -0000 Received: from unknown (HELO caip.rutgers.edu) (128.6.236.10) by sources.redhat.com with SMTP; 20 Jan 2004 01:39:56 -0000 Received: from caip.rutgers.edu (localhost [127.0.0.1]) by caip.rutgers.edu (8.12.9/8.12.9) with ESMTP id i0K1ds3K019679; Mon, 19 Jan 2004 20:39:54 -0500 (EST) Received: (from ghazi@localhost) by caip.rutgers.edu (8.12.9/8.12.9/Submit) id i0K1dsUu019678; Mon, 19 Jan 2004 20:39:54 -0500 (EST) Date: Tue, 20 Jan 2004 01:39:00 -0000 From: "Kaveh R. Ghazi" Message-Id: <200401200139.i0K1dsUu019678@caip.rutgers.edu> To: mark@codesourcery.com Subject: Re: [RFC] Contributing tree-ssa to mainline Cc: Joe.Buck@synopsys.COM, dnovillo@redhat.com, gcc@gcc.gnu.org, law@redhat.com References: <1074298740.3147.79.camel@frodo.toronto.redhat.com> <1074366070.3537.36.camel@minax.codesourcery.com> X-SW-Source: 2004-01/txt/msg01421.txt.bz2 > (B) The new C++ parser is a fair analogy, although clearly the new C++ > parser was a much smaller piece of work. It is only about 15,000 > lines of code. It only affects C++. It's not nearly as risky to the > overall project as tree-ssa. My use of the C++ parser analogy was not in reference to it's code size or scope across the compiler. Rather it was to your attentiveness to fixing regressions in it and continuing to improve it post-merge. Jeff has offered such a commitment from Redhat towards tree-ssa here: http://gcc.gnu.org/ml/gcc/2004-01/msg01304.html I also agree with Joe that we should consider bumping to version 4.0 after we merge tree-ssa: http://gcc.gnu.org/ml/gcc/2004-01/msg01408.html I think it properly communicates the amount of change under the hood to users. Whether the merge and major version bump is the next release series or the one following that is separate IMHO. But if we can count on dedicated support for fixing regression bugs and documentation now, I think we should accept it and merge. For various reasons, that commitment may not be available six months or a year later which seems to be the typical time between release series. --Kaveh -- Kaveh R. Ghazi ghazi@caip.rutgers.edu