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

Frans Meulenbroeks fransmeulenbroeks at gmail.com
Sun Jan 2 11:29:22 UTC 2011


There hasn't been too much discussion on Marcin's proposal below
(maybe lots of people enjoyed a good Xmas holiday!)

I still feel Marcin's proposal is a good plan.
Do we want to move this way?

If so, what about some action?

Frans


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
>  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
>
> 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.
>
>> >> 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.
>
>> 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 ;)
>
>> 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.
>
> 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.
>
> Regards,
> --
> JID:      hrw at jabber.org
> Website:  http://marcin.juszkiewicz.com.pl/
> LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
>




More information about the Openembedded-devel mailing list