[openrisc] Re: ports to 2.96 and 3.1 versions

[Robert Lipe <robertlipe@usa.net>]

> > Do we have any chances to be in 3.1 release?
> 
> That would be someone elses call.  Depends upon how cleanly your code
> drops in.  The cleaner it is, the more likely it might be able to go
> in, the less clean, the more invasive the changes, the less likely it
> will make the 3.1 release, though, even if it doesn't, it should be
> able to make it in for 3.1.1 (if you can clean it up for submission
> quality).  Offhand, I'd say slim to none.  It should be dropped into
> mainline first, before the release branch.

We really should revisit this process since we have had a couple of ports
recently that are in this same flight pattern.

If we could get the bulky stuff of a new port reviewed, approved, and
installed early, wouldn't that be a Good Thing?  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.

Note that the resulting compiler might not actually *work* on that
target; that's probably OK.  Without asking, I'm sure the new CPU guys
would much rather distribute a few patches to the common files that
are still pending review or are being withheld becuase of development
risk than to distribute their own version or bulky patches.  So if they
needed a fix to a couple common/shared files that we couldn't accept at
this point in the cycle, they could distribute a much smaller patch kit
and not disrupt the targets that are in the release criteria.  It would
also help reduce divergence and merge grief becuaes the guys would be
closer to working in the official trees and would benefit from the bulk
edits that are so frequently done on the back-ends.

Would that work?

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