On Wed, Oct 2, 2013 at 3:49 PM, Andrew Haley <a...@redhat.com> wrote: > On 10/02/2013 01:46 PM, David Edelsohn wrote: >> >> On Wed, Oct 2, 2013 at 4:31 AM, Andrew Haley<a...@redhat.com> 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.
