From: Paul Eggleton <paul.eggleton@linux.intel.com>
To: Martin Jansa <martin.jansa@gmail.com>
Cc: Koen Kooi <koen@dominion.thruhere.net>,
openembedded-devel@lists.openembedded.org,
openembedded-core@lists.openembedded.org
Subject: Re: [oe] Piglit in Poky
Date: Fri, 03 Jan 2014 13:50:48 +0000 [thread overview]
Message-ID: <1694437.j8KFTqxpoU@helios> (raw)
In-Reply-To: <20140103133727.GE3707@jama>
On Friday 03 January 2014 14:37:27 Martin Jansa wrote:
> On Fri, Jan 03, 2014 at 01:26:05PM +0000, Paul Eggleton wrote:
> > On Friday 03 January 2014 13:25:13 Andrei Gherzan wrote:
> > > On Sun, Dec 29, 2013 at 04:44:52PM +0100, Koen Kooi wrote:
> > > > -----BEGIN PGP SIGNED MESSAGE-----
> > > > Hash: SHA1
> > > >
> > > > Philip Balister schreef op 28-12-13 23:33:
> > > > > On 12/28/2013 10:28 AM, Koen Kooi wrote:
> > > > >> Paul Eggleton schreef op 28-12-13 12:48:
> > > > >>> Hi Koen,
> > > > >>>
> > > > >>> On Tuesday 24 December 2013 15:22:32 Koen Kooi wrote:
> > > > >>>> Burton, Ross schreef op 23-12-13 19:01:
> > > > >>>>> We'd like to integrate Piglit (an OpenGL test suite) into Poky
> > > > >>>>> so that we can run automated QA on the GL stack. Piglit is
> > > > >>>>> currently residing in meta-oe, but as Poky is a self-contained
> > > > >>>>> project we can't just add meta-oe to it: apart from the size of
> > > > >>>>> meta-oe, we can't ensure stability if meta-oe makes incompatible
> > > > >>>>> changes that affect Poky.
> > > > >>>>>
> > > > >>>>> Piglit isn't a stand-alone package, there are the dependencies
> > > > >>>>> of waffle, python-mako and python-numpy to consider too. There
> > > > >>>>> are two possibilities I can see:
> > > > >>>>>
> > > > >>>>> 1) Move piglit and deps to oe-core. Piglit is for QA purposes
> > > > >>>>> only and pushes the boundaries of "core platform". In a sense
> > > > >>>>> this is a repeat of the discussion we had with Midori... does
> > > > >>>>> oe-core contain everything needed to sufficiently exercise the
> > > > >>>>> core components it ships or not?
> > > > >>>>>
> > > > >>>>> 2) Add piglit and deps to meta-yocto. Probably a new layer
> > > > >>>>> called meta-yocto-qa (or similar) because the Yocto Compatible
> > > > >>>>> guidelines forbid mixing distribution policy and recipes.
> > > > >>>>
> > > > >>>> Speaking of layers, can you *please* rename meta-yocto to
> > > > >>>> meta-poky? It's what it's actually is and would remove a lot of
> > > > >>>> confusion when trying to explain that yocto is not a distro, even
> > > > >>>> if the distro layer is called 'meta-yocto'.
> > > > >>>
> > > > >>> This is a tangent, but a couple of points:
> > > > >>>
> > > > >>> 1) This rename would not come for free. We'd need to update
> > > > >>> people's
> > > > >>> existing bblayers.conf files on the fly, as we did when
> > > > >>> meta-yocto-bsp was split out of meta-yocto, and thus bump
> > > > >>> LCONF_VERSION; however, doing this only in poky has resulted in
> > > > >>> annoying problems when users remove poky from their configurations
> > > > >>> (since LCONF_VERSION is out-of-step between Poky and OE-Core,
> > > > >>> leading
> > > > >>> to confusing errors in this situation). Thus I think we'd want to
> > > > >>> solve this once and for all by bumping the value in OE-Core as
> > > > >>> well
> > > > >>> as Poky.
> > > > >>>
> > > > >>> 2) If you propose this rename, perhaps you will also consider
> > > > >>> renaming meta-oe, since that name within a similarly named
> > > > >>> meta-openembedded repository leads to a similar level of
> > > > >>> confusion...?
> > > > >>
> > > > >> I have no problems with renaming that layer since I get confused by
> > > > >> this a few times a week myself :)
> > > > >
> > > > > What would we we rename it to?
> > > >
> > > > I'm very tempted to suggest 'meta-yocto'
> > >
> > > I definitely find meta-yocto a better option here. It would save me from
> > > some confusion when talking about yocto to other people.
> >
> > I'm not following; meta-yocto is already called meta-yocto ... ? Maybe you
> > didn't realise Koen was joking...
>
> My understanding was that Koen was talking about renaming
> meta-openembedded repository to meta-yocto, which would be kind of nice,
> but too late for that now, it would be very confusing with the other
> meta-yocto repository.
I don't think that would be possible anyway. The Yocto Project itself does not
officially maintain support for the contents of that repository. It's true that
I'm maintaining meta-webserver and folks at Wind River are maintaining meta-
networking and some other bits and pieces, but AIUI that work isn't officially
under the Yocto Project umbrella - e.g. we do not run these through our QA /
testing / release processes like we do Poky / OE-Core.
> > > Related to meta-oe, even if that would be a smaller problem, I think
> > > meta-openembedded is a better name for that layer too.
> >
> > That doesn't solve the problem I was talking about, namely that there's
> > little distinction between meta-openembedded the repository (that
> > contains a number of layers) and meta-oe which is one of those layers.
> > These are two different things and the similar naming makes it hard to
> > always know which one people are talking about.
FWIW, I didn't yet mention my suggestion - I was thinking about meta-oe (the
layer) being renamed to "meta-misc" in the absence of some better suggestion.
I'm sure we could have a transition mechanism via a specialised layer.conf
where the old name continues to work for a limited time.
> What's even worse is that github mirror names the repositories
> meta-oe/oe-core so even the small distinction "meta-openembedded" =
> repo, "meta-oe" = layer doesn't work there.
>
> https://github.com/openembedded
Yes, that should definitely be changed as well. They're supposed to be mirrors
so they should have the exact same names, IMHO.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
next prev parent reply other threads:[~2014-01-03 13:51 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-23 18:01 Piglit in Poky Burton, Ross
2013-12-24 1:09 ` Philip Balister
2013-12-24 10:50 ` [oe] " Martin Jansa
2014-01-06 11:22 ` Paul Eggleton
2013-12-28 11:41 ` Paul Eggleton
2014-01-08 16:09 ` Burton, Ross
2014-01-08 16:27 ` [poky] " Martin Jansa
2014-01-08 17:01 ` Richard Purdie
2014-01-08 17:14 ` Nicolas Dechesne
2014-01-08 18:44 ` Philip Balister
2014-01-08 19:46 ` Burton, Ross
2014-01-08 21:14 ` [oe] " Otavio Salvador
2013-12-24 14:22 ` Koen Kooi
2013-12-28 11:48 ` Paul Eggleton
2013-12-28 15:28 ` Koen Kooi
2013-12-28 22:33 ` Philip Balister
2013-12-29 15:44 ` Koen Kooi
2014-01-03 11:25 ` Andrei Gherzan
2014-01-03 13:26 ` [oe] " Paul Eggleton
2014-01-03 13:37 ` Martin Jansa
2014-01-03 13:50 ` Paul Eggleton [this message]
2014-01-03 15:06 ` Andrei Gherzan
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=1694437.j8KFTqxpoU@helios \
--to=paul.eggleton@linux.intel.com \
--cc=koen@dominion.thruhere.net \
--cc=martin.jansa@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
--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