[oe] [RFC] Make some big changes right after next stable

[Tom Rini]

On Wed, 2010-03-03 at 18:20 +0100, Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 03-03-10 17:30, Tom Rini wrote:
> > Hey all,
> > 
> > I'd like to see some comments on the following idea.
> > 
> > As many people know, there's a lot of "odd" internal things that OE
> > does, that if we had it to do over, we would do differently.  What I
> > would like to propose is that in time for the next stable branch we:
> > 1: Define a set of DISTROs/MACHINEs/build targets that need to stay
> > working
> > 2: In a separate branch (per big change), get one of these big, going to
> > leave some stuff broken changes
> > 3: Define / document what needs to be done before these branches can be
> > merged back (something like #1 is working still, and if applicable a
> > guide to the common problems/how to fix people are going to run into).
> > 
> > What I'm getting at is that this would let us do things like rework the
> > "this is where we place things that we build other recipes with" concept
> > so that sysroot just works (and otherwise makes more sense again).  Or
> > "let us have more consistency in build with compared to what could end
> > up on device".  And so on.
> > 
> > What do people think?  And what would people work on?
> 
> I don't think we need to wait for a next stable to happen. I personally
> think a new stable branch can only happen after all legacy staging has
> been eradicated. And when people not using the stable branches stop
> spreading FUD about them.

Note that I'm not talking about "small" things like removing legacy
staging stuff (which is good!) I'm talking about things with the
potential to leave stuff non-building until stumbled upon.  Hence the
idea we do merge this into dev shortly after the next stable.

-- 
Tom Rini <tom_rini at mentor.com>
Mentor Graphics Corporation