Openembedded Devel Discussions
 help / color / mirror / Atom feed
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 --]

  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