All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [RFC] meta-openembedded layer for yocto hosted on oe.org
Date: Tue, 21 Dec 2010 18:51:25 +0100	[thread overview]
Message-ID: <AANLkTimv-=g7qhYQynPYi65Vp2sQk_a6mPUsVbh-M0eA@mail.gmail.com> (raw)
In-Reply-To: <iepnom$tk9$1@dough.gmane.org>

2010/12/21 Koen Kooi <k.kooi@student.utwente.nl>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 20-12-10 18:16, Frans Meulenbroeks wrote:
>> 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.

Ah ok.
Seems a good plan.
>
>> 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.
Maybe this should be one of the items to be discussed with the yocto
board (and maybe come to one user contributed layer).

BTW it seems good to come up with some guidelines on the
meta-openembedded layer (or maybe usage rules or so).
E.g. personally I would expect that if I put meta-openembedded on top
of e.g. poky/laverne that a recipe in it builds).
So no dependencies on non poky recipes. Is that an agreed assumption?

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.

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.
But I guess this is more something for a different thread.

Frans



  reply	other threads:[~2010-12-21 17:51 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 [this message]
2010-12-21 18:41         ` Khem Raj
2010-12-21 20:28         ` Marcin Juszkiewicz
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='AANLkTimv-=g7qhYQynPYi65Vp2sQk_a6mPUsVbh-M0eA@mail.gmail.com' \
    --to=fransmeulenbroeks@gmail.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.