All of lore.kernel.org
 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


WARNING: multiple messages have this Message-ID (diff)
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-core] 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: 44+ 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  1:09   ` [OE-core] " Philip Balister
2013-12-24 10:50   ` [oe] " Martin Jansa
2013-12-24 10:50     ` [OE-core] " Martin Jansa
2013-12-24 10:50     ` [oe] " Martin Jansa
2014-01-06 11:22     ` Paul Eggleton [this message]
2014-01-06 11:22       ` Paul Eggleton
2013-12-28 11:41   ` Paul Eggleton
2013-12-28 11:41     ` [OE-core] " Paul Eggleton
2014-01-08 16:09   ` Burton, Ross
2014-01-08 16:09     ` [OE-core] " Burton, Ross
2014-01-08 16:27     ` [poky] " Martin Jansa
2014-01-08 16:27       ` [poky] [OE-core] " Martin Jansa
2014-01-08 16:27       ` Martin Jansa
2014-01-08 17:01     ` Richard Purdie
2014-01-08 17:01       ` [OE-core] " Richard Purdie
2014-01-08 17:01       ` Richard Purdie
2014-01-08 17:14       ` Nicolas Dechesne
2014-01-08 17:14         ` [OE-core] " Nicolas Dechesne
2014-01-08 18:44       ` Philip Balister
2014-01-08 18:44         ` [OE-core] " Philip Balister
2014-01-08 19:46         ` Burton, Ross
2014-01-08 19:46           ` [OE-core] " Burton, Ross
2014-01-08 19:46           ` Burton, Ross
2014-01-08 21:14       ` [oe] " Otavio Salvador
2014-01-08 21:14         ` [OE-core] " Otavio Salvador
2013-12-24 14:22 ` Koen Kooi
2013-12-28 11:48   ` Paul Eggleton
2013-12-28 11:48     ` [OE-core] " Paul Eggleton
2013-12-28 15:28     ` Koen Kooi
2013-12-28 22:33       ` Philip Balister
2013-12-28 22:33         ` [OE-core] " Philip Balister
2013-12-29 15:44         ` Koen Kooi
2014-01-03 11:25           ` Andrei Gherzan
2014-01-03 11:25             ` [OE-core] " Andrei Gherzan
2014-01-03 13:26             ` [oe] " Paul Eggleton
2014-01-03 13:26               ` [OE-core] " Paul Eggleton
2014-01-03 13:37               ` [oe] " Martin Jansa
2014-01-03 13:37                 ` [OE-core] " Martin Jansa
2014-01-03 13:50                 ` [oe] " Paul Eggleton
2014-01-03 13:50                   ` [OE-core] " Paul Eggleton
2014-01-03 15:06               ` [oe] " Andrei Gherzan
2014-01-03 15:06                 ` [OE-core] " 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 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.