From: Marcin Juszkiewicz <marcin@juszkiewicz.com.pl>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [RFC] meta-openembedded layer for yocto hosted on oe.org
Date: Tue, 21 Dec 2010 21:28:13 +0100 [thread overview]
Message-ID: <201012212128.17392.marcin@juszkiewicz.com.pl> (raw)
In-Reply-To: <AANLkTimv-=g7qhYQynPYi65Vp2sQk_a6mPUsVbh-M0eA@mail.gmail.com>
[-- Attachment #1: Type: Text/Plain, Size: 3600 bytes --]
Dnia wtorek, 21 grudnia 2010 o 18:51:25 Frans Meulenbroeks napisał(a):
> 2010/12/21 Koen Kooi <k.kooi@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@jabber.org
Website: http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
next prev parent reply other threads:[~2010-12-21 20:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-20 15:53 [RFC] meta-openembedded layer for yocto hosted on oe.org Koen Kooi
2010-12-20 16:56 ` Graeme Gregory
2010-12-20 17:16 ` Frans Meulenbroeks
2010-12-20 19:25 ` Maupin, Chase
2010-12-20 20:31 ` Frans Meulenbroeks
2010-12-21 8:16 ` Koen Kooi
2010-12-21 17:51 ` Frans Meulenbroeks
2010-12-21 18:41 ` Khem Raj
2010-12-21 20:28 ` Marcin Juszkiewicz [this message]
2010-12-21 21:16 ` Frans Meulenbroeks
2011-01-02 11:29 ` Frans Meulenbroeks
2010-12-22 5:43 ` Esben Haabendal
2010-12-21 9:45 ` Khem Raj
2010-12-21 18:48 ` Tom Rini
2010-12-21 19:25 ` Cliff Brake
2010-12-21 20:39 ` Chris Larson
2010-12-21 15:43 ` Cliff Brake
2010-12-21 16:25 ` Koen Kooi
2010-12-21 21:03 ` Denys Dmytriyenko
2010-12-22 11:19 ` Koen Kooi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201012212128.17392.marcin@juszkiewicz.com.pl \
--to=marcin@juszkiewicz.com.pl \
--cc=openembedded-devel@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox