[oe] [RFC] meta-openembedded layer for yocto hosted on oe.org

[Frans Meulenbroeks]

Marcin, thanks for the good post!

2010/12/21 Marcin Juszkiewicz <marcin at juszkiewicz.com.pl>:
> Dnia wtorek, 21 grudnia 2010 o 18:51:25 Frans Meulenbroeks napisał(a):
>> 2010/12/21 Koen Kooi <k.kooi at student.utwente.nl>:
>> >> Nice piece of work & a good plan but...
>> >> Who will be the owners/maintainers of the layers?
>> >
>> > My intention was that the meta-openembedded layer will be maintained by
>> > the people interested in it. There will be a new MAINTAINERS file inside
>> > listing who feels responsible for various recipes.
>
>> Seems a good plan.
>
> I just gave on irc how I see cooperation with Yocto:
>
> - yocto-core layer - maintained by Yocto, builds always for selected targets,
>  pull only way of providing changes - just like Poky was
> - oe-core layer - extra images, classes required by OE builds. Same policies

Good plan.
I guess we need to decide on the procedure for something to get in.
I would propose that we maintain a version policy similar to yocto (if
I recall correctly what RP wrote about it, it was e.g. preferably only
one version of a recipe and keeping a fairly close tracking of new
versions, forgot the other wise words he said on the topic).
The key probem to me seems to be how to deal with new versions of e.g.
libs. Toolchain changed will probably be driven by yocto.
And ofc we need a volunteer (or some) to pull, verify that it works etc)

>  as Yocto core - only pull from user branches if changes pass test builds
> - oe-distro-DISTRO (for those distros which needs own layers - like angstrom
>  does) maintained by distro maintainers with their policies
> - oe-bsp-STH maintained by layer maintainers with their policies
> - oe-extra-STH (STH = opie, xfce, whatever) maintained by person/team
> - oe-unmaintained layer with everything not fit in layers

Seems a nice split to me.
>
> This way we can get stable core (yocto-core + oe-core) which builds always for
> selected targets + layers with UI environments, multimedia, boards/soc
> support, etc each of them maintained by person or team. How we will split
> metadata into layers (and subdirs in layers) is other thing and will need to
> be discussed too.

I can also imagine testing comes around the corner here.
E.g. the OE-core maintainer pulls/picks changes, gives it a testing
tag then some people fire off testing builds, if these are all ok, the
changes get promoted.
But ofc we can also think about other scenarios.
(or maybe instead of testing we have a core-next layer that is
promoted to core once testing is succesful.

>
>> >> An alternate approach would be to let the stuff live in poky-extras.
>> >> See this proposal from RP:
>> >> http://www.mail-archive.com/yocto@yoctoproject.org/msg00286.html
>> >
>> > The poky-extras thing is not what I want, and more importantly, I don't
>> > want to start diluting the OE brand.
>>
>> Why wouldn't you want poky-extras?
>> My concern is that we get lots of duplicated effort because both
>> poky-extras and meta-openembedded might get the same recipes.
>
> Poky-extras is part of Poky not OpenEmbedded. Our brand has 7 years and we do
> not want to let it disappear. This will send wrong message to people who use
> our work.

I agree on that.But it must be clear what our added value is.

>
>> Wrt diluting the OE brand. This is a completely different topic.
>> IMHO the mere fact that yocto exists impacts OE.
>> Yocto also has much more resources (both people-hour wise as well as
>> HW wise), so I strongly doubt we can compete on it wrt the quality of
>> the base recipes.
>
> Thats why we should move to use Yocto as base. We have skilled developers too
> which can and will provide changes to yocto-core layer. But those changes will
> require testing before being merged which can be new thing for some of OE
> developers ;)

Agree.
>
>> That leaves the question:
>> Given the existence of Yocto in which parts do we see added value of
>> OE and on which things should we as OE focus.
>
> OE supports more targets then Yocto does or will ever support. I do not expect
> Yocto to support Intel Mainstone or Simpad or even Alix.1c which I use for my
> router. But OE supports those machines (more or less) and this is our value.
> There are boards outside which boots to OpenEmbedded derived root filesystems
> - not Yocto or Poky but OE based.

I agree. Actually I have a few of these boards myself.
But we're more than a bunch of BSP layers. (I don't think we disagree
on this :-) )
>
> If we do proper separation of layers then who knows - maybe some vendors which
> base on OE will start to base on Yocto directly. But as OE will also base on
> Yocto then it will be not a problem to use vendor layers with our ones to
> provide extra packages.

Sure. I might even work for such a company!

Frans