Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Paul Eggleton <paul.eggleton@linux.intel.com>
To: Martin Jansa <martin.jansa@gmail.com>
Cc: openembedded-devel@lists.openembedded.org,
	openembedded-core@lists.openembedded.org
Subject: Re: [oe] Piglit in Poky
Date: Mon, 06 Jan 2014 11:22:55 +0000	[thread overview]
Message-ID: <1424614.QymdokhKXO@helios> (raw)
In-Reply-To: <20131224105050.GX3706@jama>

On Tuesday 24 December 2013 11:50:50 Martin Jansa wrote:
> On Mon, Dec 23, 2013 at 08:09:30PM -0500, Philip Balister wrote:
> > On 12/23/2013 01:01 PM, Burton, Ross wrote:
> > > 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?
> > 
> > I expect Richard will push back on this, and I would support him here.
> > 
> > > 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.  We'd need to sync
> > > meta-yocto-qa with the pieces of meta-oe that we want somehow, but
> > > that's our problem.
> > 
> > So meta-yocto is right out. I'm a user of numpy, and I certainly do not
> > want to include something called meta-yocto-qa just to pick up numpy.
> > 
> > So this presents a quandry. Moving numpy to a special layer to support a
> > specific recipe is just not the right thing to do. Conceivably, we could
> > create a layer for the bits of meta-oe that are python related, but I am
> > not sure that solves your entire problem.
> > 
> > I certainly do not want to see one recipe appear in two layers. That is
> > a recipe for trouble.
> > 
> > Long term, we need to make the layer model work for the entire project
> > and get over the reluctance to use other peoples layers.
> 
> Agreed, meta-python in meta-oe repository sounds a lot better than
> having the same recipe in 2 layers.

FWIW, independent of this issue I'd like to see us have a meta-python layer in 
the meta-openembedded repo anyway. I'll even volunteer to maintain it if it 
helps.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre


  reply	other threads:[~2014-01-06 11:22 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 [this message]
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
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=1424614.QymdokhKXO@helios \
    --to=paul.eggleton@linux.intel.com \
    --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