[openrisc] Re: ports to 2.96 and 3.1 versions

[Robert Lipe <robertlipe@usa.net>]

[ Should probably drop opencores address from continued discussion. ] 

mike stump wrote:
> > Date: Thu, 24 Jan 2002 13:11:00 -0600
> > From: Robert Lipe <robertlipe@usa.net>
> > To: gcc@gcc.gnu.org
> 
> > We really should revisit this process since we have had a couple of
> > ports recently that are in this same flight pattern.
> 
> You'd need to communicate what you thought was broken with status quo
> and what changes you wanted to see to it and why it would be better.
> Absent at least a suggestion of how it could be made better...  I
> don't know what there is to talk about.

We have formal plan (that's http://gcc.gnu.org/develop.html for those
just tuning in) that is designed to mitigate risk as we iterate closer
to GCC releases.  The problem I'm seeing with the status quo is that we
don't have an exemption for accepting code that isn't risky.  By our
own chart, we could only accept a new CPU core (a truly new one, not
a mutation of an existing one) during statge1 and this could mean a
lengthy delay in getting that port into the tree.

If we'd like to say that the maintainers capable of reviewing a new port
(a known bottleneck) are just likely to be too busy to review/approve
such a port and not hold them out in the name of risk, that seems more
realistic. 

> Bear in mind, sometimes ports are invasive and do contain bugs
> that do affect other platforms.

Understood.  I'm certainly not looking for carte blanche on this.  I'm
asking if we should consider allowing new CPU ports that don't touch any
common files (well, other than configury or doc) in stages other than one.

> I guess the main one is this, can a new port be accepted in stage 3,
> if it is is clean enough in how it affects other ports?  Off hand, I
> don't see much harm in it, other than incomplete work being in the
> tree.  

That's the policy/question I'm trying to get clarified.  My reading is
that a new CPU port could happen only in stage1.  Like you, I'm thinking
it would be a good thing for everyone involved it if could.  If the
port was not cleanly self contained (that "invasive" thing above) those
specific changes might well have to wait.   

> Personally, I'm happy to let the release manager make the call how
> they may, and live with the decision and after we hear more about why
> the process is broken, then decide to change it.  If a release manager
> wanted to document his ideas about new ports and phase 2 or 3 on the
> web site, I think that would be reasonable and help set expectations
> of contributors.  If the steering committee wanted to set policy (and
> document it on the web page), that would seem to be reasonable.  I
> don't see that this _needs_ to be done however.

Maybe we really don't have a hole here or maybe we really don't want to
make an exemption for new ports.  Maybe we don't need a clarification
but the fact that you and I (and apparently Joe) are reading it
differently hints that we may.

I think a clarification of intent is in order.   It's a problem that's
come up at least twice in recent months.


RJL
--
To unsubscribe from openrisc mailing list please visit http://www.opencores.org/mailinglists.shtml