Getting the ARC port reviewed and accepted

Getting the ARC port reviewed and accepted

[Jeremy Bennett]

Hi all,

You've probably seen that Joern Rennecke (amylaar) has been pinging 
repeatedly for help reviewing the ARC port:

   http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02072.html

Joern is approved as a maintainer, and the tests have been reviewed and 
approved (thanks to Mike Stump). However approximately a year since the 
original submission, after making various changes suggested at that 
time, the port itself still awaits review of acceptance.

We are in the curious position of a port that has a maintainer and 
testsuite accepted, but no actual port.

What can we do to move this to completion for 4.9 stage 1? It is not the 
smallest port (the ARC is a complex reconfigurable processor family), 
but it has been in use for a long time, causes no regression errors in 
other targets, and has been submitted by a long-standing contributor to GCC.

Advice on how to move this forward much appreciated.

Thanks,


Jeremy Bennett

-- 
Tel:      +44 (1590) 610184
Cell:     +44 (7970) 676050
SkypeID: jeremybennett
Twitter: @jeremypbennett
Email:   jeremy.bennett@embecosm.com
Web:     www.embecosm.com

Re: Getting the ARC port reviewed and accepted

[Richard Biener]

On Mon, Sep 30, 2013 at 6:09 PM, Jeremy Bennett
<jeremy.bennett@embecosm.com> wrote:
> Hi all,
>
> You've probably seen that Joern Rennecke (amylaar) has been pinging
> repeatedly for help reviewing the ARC port:
>
>   http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02072.html
>
> Joern is approved as a maintainer, and the tests have been reviewed and
> approved (thanks to Mike Stump). However approximately a year since the
> original submission, after making various changes suggested at that time,
> the port itself still awaits review of acceptance.
>
> We are in the curious position of a port that has a maintainer and testsuite
> accepted, but no actual port.
>
> What can we do to move this to completion for 4.9 stage 1? It is not the
> smallest port (the ARC is a complex reconfigurable processor family), but it
> has been in use for a long time, causes no regression errors in other
> targets, and has been submitted by a long-standing contributor to GCC.
>
> Advice on how to move this forward much appreciated.

From a RM point of view we can accept a new port also during stage3 if
the required middle-end changes are minimal.

That said, GCC is still mostly volunteer driven in this area (I don't know
of any company sponsoring review of ports that are not their own ...).
Also I guess the only reviewers that are able to approve the port technically
are global reviewers (and maybe the port maintainers themselves for
port specific parts?!).  Clarification from the SC would be most welcome here,
also ideas on how to address this (recurring) issue.

Thanks,
Richard.

PS: For a company there is always the possibility to go out and contract
one of the companies that has a global reviewer on their side to work
with them getting a port integrated.

> Thanks,
>
>
> Jeremy Bennett
>
> --
> Tel:      +44 (1590) 610184
> Cell:     +44 (7970) 676050
> SkypeID: jeremybennett
> Twitter: @jeremypbennett
> Email:   jeremy.bennett@embecosm.com
> Web:     www.embecosm.com

Re: Getting the ARC port reviewed and accepted

[Andrew Haley]

On 10/01/2013 09:11 AM, Richard Biener wrote:
> On Mon, Sep 30, 2013 at 6:09 PM, Jeremy Bennett
> <jeremy.bennett@embecosm.com> wrote:
>> Hi all,
>>
>> You've probably seen that Joern Rennecke (amylaar) has been pinging
>> repeatedly for help reviewing the ARC port:
>>
>>   http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02072.html
>>
>> Joern is approved as a maintainer, and the tests have been reviewed and
>> approved (thanks to Mike Stump). However approximately a year since the
>> original submission, after making various changes suggested at that time,
>> the port itself still awaits review of acceptance.
>>
>> We are in the curious position of a port that has a maintainer and testsuite
>> accepted, but no actual port.
>>
>> What can we do to move this to completion for 4.9 stage 1? It is not the
>> smallest port (the ARC is a complex reconfigurable processor family), but it
>> has been in use for a long time, causes no regression errors in other
>> targets, and has been submitted by a long-standing contributor to GCC.
>>
>> Advice on how to move this forward much appreciated.
> 
> From a RM point of view we can accept a new port also during stage3 if
> the required middle-end changes are minimal.
> 
> That said, GCC is still mostly volunteer driven in this area (I don't know
> of any company sponsoring review of ports that are not their own ...).
> Also I guess the only reviewers that are able to approve the port technically
> are global reviewers (and maybe the port maintainers themselves for
> port specific parts?!).  Clarification from the SC would be most welcome here,
> also ideas on how to address this (recurring) issue.

I can't see the point of insisting on technicalities here.  Joern is very
experienced, capable of maintaining the port over time, and it as long
as there aren't middle-end changes it won't break anything.

Andrew.

Re: Getting the ARC port reviewed and accepted

[Richard Biener]

On Tue, Oct 1, 2013 at 11:10 AM, Andrew Haley <aph@redhat.com> wrote:
> On 10/01/2013 09:11 AM, Richard Biener wrote:
>> On Mon, Sep 30, 2013 at 6:09 PM, Jeremy Bennett
>> <jeremy.bennett@embecosm.com> wrote:
>>> Hi all,
>>>
>>> You've probably seen that Joern Rennecke (amylaar) has been pinging
>>> repeatedly for help reviewing the ARC port:
>>>
>>>   http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02072.html
>>>
>>> Joern is approved as a maintainer, and the tests have been reviewed and
>>> approved (thanks to Mike Stump). However approximately a year since the
>>> original submission, after making various changes suggested at that time,
>>> the port itself still awaits review of acceptance.
>>>
>>> We are in the curious position of a port that has a maintainer and testsuite
>>> accepted, but no actual port.
>>>
>>> What can we do to move this to completion for 4.9 stage 1? It is not the
>>> smallest port (the ARC is a complex reconfigurable processor family), but it
>>> has been in use for a long time, causes no regression errors in other
>>> targets, and has been submitted by a long-standing contributor to GCC.
>>>
>>> Advice on how to move this forward much appreciated.
>>
>> From a RM point of view we can accept a new port also during stage3 if
>> the required middle-end changes are minimal.
>>
>> That said, GCC is still mostly volunteer driven in this area (I don't know
>> of any company sponsoring review of ports that are not their own ...).
>> Also I guess the only reviewers that are able to approve the port technically
>> are global reviewers (and maybe the port maintainers themselves for
>> port specific parts?!).  Clarification from the SC would be most welcome here,
>> also ideas on how to address this (recurring) issue.
>
> I can't see the point of insisting on technicalities here.  Joern is very
> experienced, capable of maintaining the port over time, and it as long
> as there aren't middle-end changes it won't break anything.

Well, I want clarification as of whether assigning maintainership of the
port is equivalent to getting approval for checking in the port specific
parts.  Which _I_ would think is reasonable (for the maintainer being
Joern even more so).

Richard.

> Andrew.
>
>

Re: Getting the ARC port reviewed and accepted

[Andrew Haley]

On 10/01/2013 11:32 AM, Richard Biener wrote:
> Well, I want clarification as of whether assigning maintainership of the
> port is equivalent to getting approval for checking in the port specific
> parts.  Which_I_  would think is reasonable (for the maintainer being
> Joern even more so).

Well, sure it is.  If Joern is the maintainer he don't need anyone else
to approve his patches to his own port.

Andrew.

Re: Getting the ARC port reviewed and accepted

[Richard Biener]

On Tue, Oct 1, 2013 at 3:24 PM, Andrew Haley <aph@redhat.com> wrote:
> On 10/01/2013 11:32 AM, Richard Biener wrote:
>>
>> Well, I want clarification as of whether assigning maintainership of the
>> port is equivalent to getting approval for checking in the port specific
>> parts.  Which_I_  would think is reasonable (for the maintainer being
>> Joern even more so).
>
>
> Well, sure it is.  If Joern is the maintainer he don't need anyone else
> to approve his patches to his own port.

Good.  So what remains is the configure parts, the libgcc parts and
the documentation parts.  Though for all of them they look ARC
specific so maybe the maintainership covers these as well.

I suppose this automatism when being assigned the maintainership
escaped Joern as well ... ;)

Richard.

> Andrew.
>

Re: Getting the ARC port reviewed and accepted

[Joern Rennecke]

Quoting Richard Biener <richard.guenther@gmail.com>:

> Good.  So what remains is the configure parts, the libgcc parts and
> the documentation parts.  Though for all of them they look ARC
> specific so maybe the maintainership covers these as well.
>
> I suppose this automatism when being assigned the maintainership
> escaped Joern as well ... ;)

I knew that the maintainership in general covers the relevant config  
and testsuite bits as well as the port specific directories, but David  
Edelsohn
said at my appointment as maintainer:

: The GCC SC has approved acceptance of the port and you as maintainer.
: I will announce that shortly.  Because the patches that you want to
: include in GCC 4.8 are localized to the port, I think that it still
: should be possible to merge it into trunk (assuming the RMs agree),
: but you still need a Global Reviewer to approve it.

Re: Getting the ARC port reviewed and accepted

[Andrew Haley]

On 10/01/2013 03:19 PM, Joern Rennecke wrote:
> Quoting Richard Biener<richard.guenther@gmail.com>:
>
>> Good.  So what remains is the configure parts, the libgcc parts and
>> the documentation parts.  Though for all of them they look ARC
>> specific so maybe the maintainership covers these as well.
>>
>> I suppose this automatism when being assigned the maintainership
>> escaped Joern as well ... ;)
>
> I knew that the maintainership in general covers the relevant config
> and testsuite bits as well as the port specific directories, but David
> Edelsohn
> said at my appointment as maintainer:
>
> : The GCC SC has approved acceptance of the port and you as maintainer.
> : I will announce that shortly.  Because the patches that you want to
> : include in GCC 4.8 are localized to the port, I think that it still
> : should be possible to merge it into trunk (assuming the RMs agree),
> : but you still need a Global Reviewer to approve it.

Ofercrineoutloud, I'm wondering if we've changed from the Knights Of
Free Software to a bunch of clerks obsessed with process for process's
sake.

Please, there must be a Global Reviewer reading this.

Andrew.

Re: Getting the ARC port reviewed and accepted

[Jeff Law]

On 10/01/13 09:23, Andrew Haley wrote:
> On 10/01/2013 03:19 PM, Joern Rennecke wrote:
>> Quoting Richard Biener<richard.guenther@gmail.com>:
>>
>>> Good.  So what remains is the configure parts, the libgcc parts and
>>> the documentation parts.  Though for all of them they look ARC
>>> specific so maybe the maintainership covers these as well.
>>>
>>> I suppose this automatism when being assigned the maintainership
>>> escaped Joern as well ... ;)
>>
>> I knew that the maintainership in general covers the relevant config
>> and testsuite bits as well as the port specific directories, but David
>> Edelsohn
>> said at my appointment as maintainer:
>>
>> : The GCC SC has approved acceptance of the port and you as maintainer.
>> : I will announce that shortly.  Because the patches that you want to
>> : include in GCC 4.8 are localized to the port, I think that it still
>> : should be possible to merge it into trunk (assuming the RMs agree),
>> : but you still need a Global Reviewer to approve it.
>
> Ofercrineoutloud, I'm wondering if we've changed from the Knights Of
> Free Software to a bunch of clerks obsessed with process for process's
> sake.
>
> Please, there must be a Global Reviewer reading this.
Maintainership includes the obvious configury bits as well.  Joern is 
being a bit overly pedantic here.

jeff

Re: Getting the ARC port reviewed and accepted

[David Edelsohn]

On Tue, Oct 1, 2013 at 11:23 AM, Andrew Haley <aph@redhat.com> wrote:
> On 10/01/2013 03:19 PM, Joern Rennecke wrote:
>>
>> Quoting Richard Biener<richard.guenther@gmail.com>:
>>
>>> Good.  So what remains is the configure parts, the libgcc parts and
>>> the documentation parts.  Though for all of them they look ARC
>>> specific so maybe the maintainership covers these as well.
>>>
>>> I suppose this automatism when being assigned the maintainership
>>> escaped Joern as well ... ;)
>>
>>
>> I knew that the maintainership in general covers the relevant config
>> and testsuite bits as well as the port specific directories, but David
>> Edelsohn
>> said at my appointment as maintainer:
>>
>> : The GCC SC has approved acceptance of the port and you as maintainer.
>> : I will announce that shortly.  Because the patches that you want to
>> : include in GCC 4.8 are localized to the port, I think that it still
>> : should be possible to merge it into trunk (assuming the RMs agree),
>> : but you still need a Global Reviewer to approve it.
>
>
> Ofercrineoutloud, I'm wondering if we've changed from the Knights Of
> Free Software to a bunch of clerks obsessed with process for process's
> sake.
>
> Please, there must be a Global Reviewer reading this.

This hyperbolic reaction is not helpful and you have enough experience
with the GCC community to understand why a technical review is
helpful.  There clearly are alternate ways of interpreting the request
than as some bureaucratic torture test.  There are legal or other
reasons that GCC might not want to accept an offered patch (GCC SC
approval) and there have been severe technical problems with some
proposed new ports or the port may touch common areas of the compiler
(GCC global reviewer).

If some GCC Global Reviewer is confident in Joern's ability, which I
don't doubt, he can approve it based on that.

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. GCC is a community not a
dictatorship.

- David

Re: Getting the ARC port reviewed and accepted

[Andrew Haley]

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.

Andrew.

Re: Getting the ARC port reviewed and accepted

[David Edelsohn]

On Wed, Oct 2, 2013 at 4:31 AM, Andrew Haley <aph@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.

One issue is encouraging more recent but experienced GCC developers to
become maintainers.

Thanks, David

Re: Getting the ARC port reviewed and accepted

[Andrew Haley]

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

Andrew.

Re: Getting the ARC port reviewed and accepted

[Richard Biener]

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

Re: Getting the ARC port reviewed and accepted

[David Malcolm]

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

Presumably this page:
  http://gcc.gnu.org/wiki/Partial_Transitions

Out of interest, is that page itself up-to-date?  The last update was on
2012-02-17.

Thanks
Dave

Re: Getting the ARC port reviewed and accepted

[Richard Earnshaw]

On 02/10/13 14:59, Richard Biener wrote:
> 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.


There may be technical issues with doing this, but I've pondered before
the idea of having a pre-define of NEW_PORT, which has the effect of
disabling all deprecated interfaces in the compiler.  New back-end
submissions would be required to build with NEW_PORT defined at the time
of inclusion.

Once a port has been included into trunk it can then remove the NEW_PORT
restriction.

A hook like this would also be useful for working out which ports were
still relying on legacy interfaces (though I suspect today that's most
of them...).

R.

Re: Getting the ARC port reviewed and accepted

[Jeremy Bennett]

On 30/09/13 17:09, Jeremy Bennett wrote:
> Hi all,
>
> You've probably seen that Joern Rennecke (amylaar) has been pinging
> repeatedly for help reviewing the ARC port:
>
>    http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02072.html
>
> Joern is approved as a maintainer, and the tests have been reviewed and
> approved (thanks to Mike Stump). However approximately a year since the
> original submission, after making various changes suggested at that
> time, the port itself still awaits review of acceptance.
>
> We are in the curious position of a port that has a maintainer and
> testsuite accepted, but no actual port.
>
> What can we do to move this to completion for 4.9 stage 1? It is not the
> smallest port (the ARC is a complex reconfigurable processor family),
> but it has been in use for a long time, causes no regression errors in
> other targets, and has been submitted by a long-standing contributor to
> GCC.
>
> Advice on how to move this forward much appreciated.
>
A big thank you to all who stepped up to get Joern's work reviewed and 
accepted. Particularly Diego for his reviewing work.

Best wishes,


Jeremy

-- 
Tel:      +44 (1590) 610184
Cell:     +44 (7970) 676050
SkypeID: jeremybennett
Twitter: @jeremypbennett
Email:   jeremy.bennett@embecosm.com
Web:     www.embecosm.com