[oe] Yocto Project and OE - Where now?

[Koen Kooi]

Op 14 jan 2011, om 18:49 heeft Richard Purdie het volgende geschreven:

> The vote result showed a strong opinion that Yocto and OE need to find a
> way to work together which is something I'm very happy to see. I think
> everyone is waiting for each other to make a move so I'm going to put
> forward some ideas/discussion to try and start the ball rolling. I'm
> filling out ideas here but I want to make it clear this is a straw-man
> to discuss. I have given this a lot of thought though as its attention
> to many of the details that will determine its success.
> 
> The agreement for OE to take up a seat on the Yocto Steering Group seems
> to be progressing and I think that part of things is moving forward well
> and the board is handling it. At a technical level we need to have some
> discussion though.
> 
> I think the idea in people's minds is to create an "openembedded-core"
> which would have a new development structure. There are various aims for
> doing this but they include:
> 
> * Formalising processes for making changes
> * Creation of a subset of metadata that has a consistent high quality 
>  standard:
>    - removal of legacy components (pkgconfig hacks, libtool hacks, 
>      legacy staging, unneeded compiler arguments)
>    - consistent metadata layout, spacing, use of variables
>    - migration away from outdated practises (e.g. use BBCLASSEXTEND)
> * Formalise cycles of development, stabilisation and release
> * Ensure a form of standardised basic testing of changes and over time, 
>  extend that testing
> 
> We've talked about doing this at OEDEMs in the past, we keep talking
> around the issue, we now have an opportunity to attempt it and to make
> it a success. Part of the problem was always manpower to undertake some
> of it, Yocto gives us a mechanism to help with that.
> 
> What would we have to do to make that happen? Roughly speaking I think
> the steps look like:
> 
> * Agreed to try a new contributions model
> * Setup an openembedded-core repo
> * Populate that repo with some base data
> * Decide where OE core patches would be queued, discussed and processed
> * Document the process
> * Start using it
> * Profit!

I think we can start with the following right now:

* setup an oe-core repo
* populate that repo

What I propose to do in parallel to that:

* setup oe-yocto-integration mailinglist
* people interesting in *working*[1] on the integration may subscribe
* hook that ml up to patchwork as a new project

That only leaves:

* contributions model discussion
* patch processing discussion
* documentation
* profit

> For OE, we've talked about cleaning it out for a long time and I think
> meta-openembedded is the solution there with some cleanup happening as
> people transition the recipes they use.

Apart from the weird pythondir() problem that came up last week, meta-openembedded is working quite well as layer on top of yocto. It would be nice to see more people contribution to it, though.

[snip]

> One other question also springs to mind which is what is the TSC's remit
> in this new contribution mode

As we discussed during OEDEM, the TSC needs to go through an election cycle to get some new people on. The current TSC is opaque, non-responsive and out of touch. I'm not sure a new election is going to help fix that, but it's worth a try.

> Ultimately, I think the only way we're going to move forward with this
> is to actually try something.

So lets get started!


[1] Lots of people have love to suggest colours for the bikeshed, but few people actually want to do actual painting