Re: openembedded-core git repository

[Frans Meulenbroeks <fransmeulenbroeks@gmail.com>]

2011/1/19 Graeme Gregory <dp@xora.org.uk>:
> On 19/01/2011 15:33, Frans Meulenbroeks wrote:
>> 2011/1/19 Graeme Gregory <dp@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 also encourage and support a pull model, driven by one or a
few fairly neutral developers.
>
> 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.

I'm not really sure what would go into core, but I kinda figured it
would probably be something like poky/meta
http://git.pokylinux.org/cgit/cgit.cgi/poky/tree/meta

The examples I gave are maybe not desirable in a minimal setting.
Then again I feel core should probably be a little bit more than board
bringup + busybox. I would hope that recipes like perl and python
become part of core.

Then again if oe core is similar to poky/meta the things I mentioned
might fit in better than say libid3tag.
If oe core is what is now in poky/recipes-core then I fully agree that
the things I mention do not belong there (but probably glib-2.0 does
not belong in a minimal layer either).

http://git.pokylinux.org/cgit/cgit.cgi/poky/tree/meta/recipes-core

But I had the impression that most of the poky recipes should go into
oe-core (or I misunderstood that part of Richard's email).
It does not seem too wise to have two repo's with e.g. pango, zeroconf
and matchbox.
>
> 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.

I'm not sure if that is needed (at least not on for every commit).
If we are aiming for a pull model, the maintainer(s) are the only ones
that can push and I would expect them to build things (maybe using a
buildbot to cover different architectures) before pushing.

Frans