[oe] openembedded-core git repository

[Koen Kooi]

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

On 24-01-11 18:48, Khem Raj wrote:
> On Mon, Jan 24, 2011 at 8:39 AM, Philip Balister <philip at balister.org> wrote:
>> On 01/19/2011 06:48 AM, Graeme Gregory wrote:
>>>
>>> Hi, this email is sent as an ordinary member of OE.
>>>
>>> It seems to be on a technical level we are agreed that we should split
>>> parts of OE out into the so called openembedded-core which will have a
>>> stricter commit access and higher QA requirements on changes.
>>>
>>> I therefore think it is time to actually create the repository and let
>>> the people who are interested in merging the good stuff from poky with
>>> the good stuff from openembedded to create our "core". I don't think
>>> there is any need to wait on the political part of the Yocto/OE
>>> collaboration as its something we have agreed in principal to do anyway.
>>>
>>> I would request then that the TSC drive this forward with the server
>>> admins and create this repo so work can happen.
>>
>>
>> Has anything happened on this email? Has the TSC had a meeting to discuss? I
>> know it has only been a week, but people are starting to do work based on
>> these ideas and need some support from the TSC.
>>
> 
> Yes I think we should start action on it soon. I would suggest to set
> up the repository
> as first step. As someone raised question about pull model it could be
> TSC who decided
> to appoint one gatekeeper based upon availability interest and
> capability and it could be
> rotated.secondly sane Starting point would be importing yocto and then
> apply the OE improvements
> on top thirdly breakdown oe into oe-meta repo to glue with the oe-core

Ignoring the timeline a bit, since ideally we would do this around a
yocto milestone to get them to use this straight after their freeze.

The technical roadmap/todo:

* setup openembedded-core repo on oe.org
* setup oe-core ml on oe.org
* add oe-core ml to patchwork
* import yocto-core in oe-core
* start an integration branch
 o remove bitbake
 o cleanup namespace (s/yocto/OE/, s/poky/OE/)
 o split out superfluous layers (e.g. ememlow)
* start merging in OE things
 o e.g. OE gcc 4.5, toolchains for avr32, bfin, etc
* switch meta-oe to build on top of oe-core, fix issues

When that is done meta-oe can start to expand.

The non-technical roadmap/todo:

* Assign 2 gatekeepers to oe-core, one from yocto, one from OE
* sketch out decision tree (RP -> gatekeepers -> maintainers)
* work out model for meta-oe
* appoint OE member to yocto SC
* work out how to marry yocto goals (4 archs, one toolchain) to OE goals
(zillion archs, as much toolchains as we can manage)
* Work out OE roadmap and align with yocto

The above tries to restrict itself to dealing with the new oe-core, not
with how OE is going to split into layers (meta-oe, meta-graveyard, etc).
It also ignores the maintainer aspects since we will be dealing with
yocto metadata at the start. After oe-core reaches a ready enough state
we can start looking at assigning maintainers, but for the time being
let's get things done first.

So, let's start fleshing out the above roadmaps and implement them!

regards,

Koen

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

iD8DBQFNPq6WMkyGM64RGpERAmViAKCYKgJPEcLTCL+G1uugO6wQwEkfAACgrq8C
zanbxmzVZb4tgNbdwTV/fS0=
=tMf8
-----END PGP SIGNATURE-----