From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24983 invoked by alias); 31 Jul 2003 10:08:20 -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 24976 invoked from network); 31 Jul 2003 10:08:20 -0000 Received: from unknown (HELO nile.gnat.com) (205.232.38.5) by sources.redhat.com with SMTP; 31 Jul 2003 10:08:20 -0000 Received: by nile.gnat.com (Postfix, from userid 338) id AC796F2DD2; Thu, 31 Jul 2003 06:08:19 -0400 (EDT) To: aaronl@vitelus.com, s.bosscher@student.tudelft.nl Subject: Re: GCC Cc: gcc@gcc.gnu.org Message-Id: <20030731100819.AC796F2DD2@nile.gnat.com> Date: Thu, 31 Jul 2003 10:57:00 -0000 From: dewar@gnat.com (Robert Dewar) X-SW-Source: 2003-07/txt/msg02292.txt.bz2 > > I'm not sure why they think it is so difficult. It would seem that if > > the patch is architecture-specific and well-formed (ie. conforming to > > the coding style, etc), it typically just goes in, period. And patches > > to target-independent code may go through one or two review cycles, but > > again, if the patch looks good, it goes in. At least, I got the > > impression that patches are seldomly rejected. > > Copyright assignments. Please give some evidence. I think this is just a guess. In my experience, the copyright assignment is not the issue at all. The issue is precisely getting the patches to be well-formed, which requires quite a bit of work and quite a bit of knowledge about the way gcc maintenance is organized. So what often happens is that vendors prepare local patches that work fine, but definitely do not conform (for instance they have unacceptable target dependent patches).