From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13768 invoked by alias); 18 Jan 2004 07:15:55 -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 13760 invoked from network); 18 Jan 2004 07:15:53 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 18 Jan 2004 07:15:53 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0I7Frl08530; Sun, 18 Jan 2004 02:15:53 -0500 Received: from speedy.slc.redhat.com (vpn50-8.rdu.redhat.com [172.16.50.8]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0I7Fpa08129; Sun, 18 Jan 2004 02:15:51 -0500 Received: from redhat.com (law@localhost) by speedy.slc.redhat.com (8.12.10/8.12.8/Submit) with ESMTP id i0I7E5VY000968; Sun, 18 Jan 2004 00:14:06 -0700 Message-Id: <200401180714.i0I7E5VY000968@speedy.slc.redhat.com> X-Authentication-Warning: speedy.slc.redhat.com: law owned process doing -bs To: "Kaveh R. Ghazi" cc: dnovillo@redhat.com, gcc@gcc.gnu.org, gp@suse.de, jsm@polyomino.org.uk, mark@codesourcery.com, wilson@tuliptree.org Reply-To: law@redhat.com Subject: Re: [RFC] Contributing tree-ssa to mainline In-Reply-To: Your message of "Sat, 17 Jan 2004 12:04:32 EST." <200401171704.i0HH4WWn015521@caip.rutgers.edu> From: law@redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 18 Jan 2004 07:15:00 -0000 X-SW-Source: 2004-01/txt/msg01152.txt.bz2 In message <200401171704.i0HH4WWn015521@caip.rutgers.edu>, "Kaveh R. Ghazi" wri tes: >However I'd like to hear the perspective of our release manager as >well as that of some of our global write maintainers who haven't been >immersed in the branch and haven't yet spoken up before we pull the >trigger on this. Most definitely. What I really want to get out of this discussion is what we as a group think the criteria for merging ought to be. We can look at a number of different things, including but not limited to design and code reviews, compile and runtime benchmarking, regression testing across a wide range of platforms, front-end issues (Ada/g77), etc etc. I realize we already have some policies regarding merges from branches into the mainline. What I'm not clear on is whether or not we need to have a more rigorous set of policies for tree-ssa. I don't necessarily want to rehash every design decision made by the group, but I do believe that the tree-ssa developers must be able to justify their design decisions to the larger developer community. Similarly, I believe that code reviews are important and valuable. While we certainly can't force folks to review the code, if folks are willing to review, then the tree-ssa developers ought to embrace that feedback and "do the right thing" based on that feedback. A code review is certainly made more valuable if the reviewer has the design background. I guess at the root of my concerns is that while a number of the tree-ssa developers technically have the ability to approve a merge to the mainline (assuming we meet the published criteria), I'm not sure that's necessarily the right thing to do in this case. And if it's not the right thing to do, then what is the right course of action? Those are the questions I want to see us hash through. jeff