[oe] openembedded-core git repository

[Graeme Gregory]

On 19/01/2011 15:33, Frans Meulenbroeks wrote:
> 2011/1/19 Graeme Gregory <dp at xora.org.uk>:
>> 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.
>>
>> Graeme
> Graeme,
>
> Seems  a fine plan to me.
> Do we already have an idea what would be the starting base?
> And do we already have an idea on the QA requirements we want to impose on this?
> Lastly we might try to define some common understanding what is core
> and what not.
>
> I did some experiments with poky and found that some of the recipes I
> needed were missing; some of them might perhaps become part of core
> (e.g. i2ctools, squashfstools, libftdi, fastcgi), whereas others are
> quite unlikely to end up in core (e.g. urjtag). For the latter we must
> find another home (e.g. meta-openembedded), where hopefully we can
> also raise the QA bar somewhat.
>
> I'll happily contribute to raise the quality bar. However, if the goal
> is shuffling recipes without significant QA improvement or if QA
> improvement is optional, I'll probably pass.
>

Well I would hope that openembedded-core has a pull model similar to
poky/yocto but that is I think ultimately upto TSC members (with
consultation with membership). Hopefully they shall give their opinions
on the issue soon.

I would say the obvious starting point is poky, then merge OE
improvements into that. I think this would be less work than stripping
down OE to core level.

I think all the tools you have mentioned are bad examples of stuff to go
into core except possibly squashfs. Core should be purely enough to get
a busybox minimal image build in ext2/3/jffs/ubi given a machine.conf.
Basically enough to do board bringup and no more (with package
management capabilities). If core was recipes people "needed" it wouldnt
really be core fastcgi is pretty specialised bit of software.

Core should probably have a build bot which crunches a standard set of
tests on each commit so unlike OE currently people don't wake up to bad
day of debugging OE.

Graeme