[RFC] Make some big changes right after next stable

[RFC] Make some big changes right after next stable

[Tom Rini]

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?

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

Re: [RFC] Make some big changes right after next stable

[Koen Kooi]

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

regards,

Koen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLjppqMkyGM64RGpERAhAgAJ4svJi623kKEml/uUI0/s6uuOWmFQCgthSW
pCImVyjJ3TI5BSQAiZWS9Zw=
=gO4h
-----END PGP SIGNATURE-----

Re: [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@mentor.com>
Mentor Graphics Corporation

Re: [RFC] Make some big changes right after next stable

[Graeme Gregory]

On Wed, Mar 03, 2010 at 10:33:07AM -0700, Tom Rini wrote:
> 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.
> 
I think you are approaching things backwards.

Develop this to the point of working enough other people can start to test it
in a feature branch.

Tag org.openembedded.dev then merge this work into .dev

Anyone in the future can use the tag to get back to a "stable" point.

Graeme

Re: [RFC] Make some big changes right after next stable

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03-03-10 19:08, Graeme Gregory wrote:
> On Wed, Mar 03, 2010 at 10:33:07AM -0700, Tom Rini wrote:
>> 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.
>>
> I think you are approaching things backwards.
> 
> Develop this to the point of working enough other people can start to test it
> in a feature branch.
> 
> Tag org.openembedded.dev then merge this work into .dev
> 
> Anyone in the future can use the tag to get back to a "stable" point.

That's what I wanted to say, but Graeme put it way better :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLjqeSMkyGM64RGpERAmvHAJ4q4v5Ig/lnD2UaW7ffx3R6T1AFdwCeIJcI
bJ9NE/LbnxvZfMzuuvjqAv8=
=rTPS
-----END PGP SIGNATURE-----

Re: [RFC] Make some big changes right after next stable

[Tom Rini]

On Wed, 2010-03-03 at 18:08 +0000, Graeme Gregory wrote:
> On Wed, Mar 03, 2010 at 10:33:07AM -0700, Tom Rini wrote:
> > 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.
> > 
> I think you are approaching things backwards.
> 
> Develop this to the point of working enough other people can start to test it
> in a feature branch.
> 
> Tag org.openembedded.dev then merge this work into .dev
> 
> Anyone in the future can use the tag to get back to a "stable" point.

Let me try and make an analogy with (how I recall anyhow) kernel
development going.  As an example, re-laying out staging/ (and probably
killing cross/) happens in a branch.  Works for me.  Then still works
for some relatively big set (think -next) of targets.  I'm using the
next stable branching point as an analogy for a release + -rc1 merge
window opening up.

If everyone thinks that's just overkill, Chris will just start on the
new pstaging in a branch somewhere pretty soon I hope then.

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

Re: [RFC] Make some big changes right after next stable

[Michael 'Mickey' Lauer]

Am Mittwoch, den 03.03.2010, 09:30 -0700 schrieb Tom Rini:
> 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 think that's a very good idea. Phil wanted to branch off a new stable
branch lately, so we can coordinate the right point of time with him.

I'd revamp EFL packaging, which is somewhat inflexible, and take a look
at bringing the Python recipes up to par.

Cheers,

-- 
:M:

Re: [RFC] Make some big changes right after next stable

[Richard Purdie]

On Wed, 2010-03-03 at 09:30 -0700, Tom Rini wrote:
> 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

It was commented at OEDEM that it would be nice to have this magic list.
We still don't have one though.

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

It makes sense.

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

This is the problem, it would be you taking this on, you'd be the person
who needed to fix things, then you would get to merge back. I don't
think we have enough people around that people would volunteer to fix
branches like that.

But by all means prove me wrong.

Cheers,

Richard