[openrisc] Re: ports to 2.96 and 3.1 versions

[mike stump <mrs@windriver.com>]

> 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.

> If we could get the bulky stuff of a new port reviewed, approved, and
> installed early, wouldn't that be a Good Thing?

Agreed.

> If we could get all the configury gunk and the totally new files in,
> there would be no risk to existing targets and could therefore
> reasonably go in at this point in the cycle.

Agreed (if the maintainer that is reviewing the patches feels this is
true).  Bear in mind, sometimes ports are invasive and do contain bugs
that do affect other platforms.

> Would that work?

I don't see much disagreement between what you've said, and what
little I know of the policy.


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.  If we mandate it only goes in as last as stage2, stage3 is
there to put the finishing touches on the port.  Or, we could accept
it as late as stage3 because it doesn't affect other ports.

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.
--
To unsubscribe from openrisc mailing list please visit http://www.opencores.org/mailinglists.shtml