From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24143 invoked by alias); 2 Oct 2013 13:59:37 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 24128 invoked by uid 89); 2 Oct 2013 13:59:36 -0000 Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com) (74.125.82.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 02 Oct 2013 13:59:36 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,NO_RELAYS autolearn=ham version=3.3.2 X-HELO: mail-wg0-f41.google.com Received: by mail-wg0-f41.google.com with SMTP id l18so6415597wgh.2 for ; Wed, 02 Oct 2013 06:59:33 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.119.106 with SMTP id kt10mr745705wjb.72.1380722373062; Wed, 02 Oct 2013 06:59:33 -0700 (PDT) Received: by 10.195.12.114 with HTTP; Wed, 2 Oct 2013 06:59:32 -0700 (PDT) In-Reply-To: <524C2468.201@redhat.com> References: <5249A23F.8000901@embecosm.com> <524A9173.30301@redhat.com> <524ACD05.2020701@redhat.com> <20131001101941.n710f8j688owg4oo-nzlynne@webmail.spamcop.net> <524AE8FF.2010101@redhat.com> <524BD9EE.1080300@redhat.com> <524C2468.201@redhat.com> Date: Wed, 02 Oct 2013 13:59:00 -0000 Message-ID: Subject: Re: Getting the ARC port reviewed and accepted From: Richard Biener To: Andrew Haley Cc: David Edelsohn , Joern Rennecke , jeremy.bennett@embecosm.com, David Edelsohn , GCC Development Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2013-10/txt/msg00036.txt.bz2 On Wed, Oct 2, 2013 at 3:49 PM, Andrew Haley wrote: > On 10/02/2013 01:46 PM, David Edelsohn wrote: >> >> On Wed, Oct 2, 2013 at 4:31 AM, Andrew Haley wrote: >>> >>> On 10/02/2013 12:47 AM, David Edelsohn wrote: >>>> >>>> It is unfortunate that global reviewers are so busy that they cannot >>>> review the few, infrequent new port submissions. But I find it very >>>> distasteful for someone to hyperventilate because other, busy people >>>> don't do something that appears obvious. >>> >>> >>> I'm sure you do, but I find it far more distasteful to have a willing >>> volunteer blocked for so long under such circumstances. This is not >>> the way that we should be doing things. >> >> >> Productive, helpful suggestions on how to improve the situation are >> welcome. > > > Clearly, insisting that only one of the few global maintainers can > review the port is a problem. Global maintainers don't scale. There > is no reason why the maintainer of another port can't review this > port. It doesn't necessarily need an global maintainer. > > While a technical review of the port would undoubtedly be helpful, it > does not make any sense to block the ARC port until it receives one: > this is an unbounded wait. > > If there aren't any middle-end changes, the consequence of an ARC port > that's not good is at worst an ARC port in GCC that is not good. Even > if there are middle-end changes, these can be reviewed separately. > > The downside of continuing to block this submission for another year > is obvious, and is, I submit, worse than the downside of accepting a > port that still needs some work. The main reason for technical review of a port is to avoid that it uses deprecated mechanisms and thus blocks removal of them. Like accepting a port that uses target macros when a corresponding target hook exists, or accepting a port that uses reload instead of LRA, or any other partial transition thing we had this matrix for somewhere somewhen. Richard. > Andrew.