<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 3, 2014 at 3:26 PM, Paul Eggleton <span dir="ltr">&lt;<a href="mailto:paul.eggleton@linux.intel.com" target="_blank">paul.eggleton@linux.intel.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Friday 03 January 2014 13:25:13 Andrei Gherzan wrote:<br>
&gt; On Sun, Dec 29, 2013 at 04:44:52PM +0100, Koen Kooi wrote:<br>
&gt; &gt; -----BEGIN PGP SIGNED MESSAGE-----<br>
&gt; &gt; Hash: SHA1<br>
&gt; &gt;<br>
&gt; &gt; Philip Balister schreef op 28-12-13 23:33:<br>
&gt; &gt; &gt; On 12/28/2013 10:28 AM, Koen Kooi wrote:<br>
&gt; &gt; &gt;&gt; Paul Eggleton schreef op 28-12-13 12:48:<br>
&gt; &gt; &gt;&gt;&gt; Hi Koen,<br>
&gt; &gt; &gt;&gt;&gt;<br>
&gt; &gt; &gt;&gt;&gt; On Tuesday 24 December 2013 15:22:32 Koen Kooi wrote:<br>
&gt; &gt; &gt;&gt;&gt;&gt; Burton, Ross schreef op 23-12-13 19:01:<br>
&gt; &gt; &gt;&gt;&gt;&gt;&gt; We&#39;d like to integrate Piglit (an OpenGL test suite) into Poky<br>
&gt; &gt; &gt;&gt;&gt;&gt;&gt; so that we can run automated QA on the GL stack.  Piglit is<br>
&gt; &gt; &gt;&gt;&gt;&gt;&gt; currently residing in meta-oe, but as Poky is a self-contained<br>
&gt; &gt; &gt;&gt;&gt;&gt;&gt; project we can&#39;t just add meta-oe to it:  apart from the size of<br>
&gt; &gt; &gt;&gt;&gt;&gt;&gt; meta-oe, we can&#39;t ensure stability if meta-oe makes incompatible<br>
&gt; &gt; &gt;&gt;&gt;&gt;&gt; changes that affect Poky.<br>
&gt; &gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt; &gt;&gt;&gt;&gt;&gt; Piglit isn&#39;t a stand-alone package, there are the dependencies<br>
&gt; &gt; &gt;&gt;&gt;&gt;&gt; of waffle, python-mako and python-numpy to consider too.  There<br>
&gt; &gt; &gt;&gt;&gt;&gt;&gt; are two possibilities I can see:<br>
&gt; &gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt; &gt;&gt;&gt;&gt;&gt; 1) Move piglit and deps to oe-core.  Piglit is for QA purposes<br>
&gt; &gt; &gt;&gt;&gt;&gt;&gt; only and pushes the boundaries of &quot;core platform&quot;.  In a sense<br>
&gt; &gt; &gt;&gt;&gt;&gt;&gt; this is a repeat of the discussion we had with Midori...  does<br>
&gt; &gt; &gt;&gt;&gt;&gt;&gt; oe-core contain everything needed to sufficiently exercise the<br>
&gt; &gt; &gt;&gt;&gt;&gt;&gt; core components it ships or not?<br>
&gt; &gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt; &gt;&gt;&gt;&gt;&gt; 2) Add piglit and deps to meta-yocto.  Probably a new layer<br>
&gt; &gt; &gt;&gt;&gt;&gt;&gt; called meta-yocto-qa (or similar) because the Yocto Compatible<br>
&gt; &gt; &gt;&gt;&gt;&gt;&gt; guidelines forbid mixing distribution policy and recipes.<br>
&gt; &gt; &gt;&gt;&gt;&gt;<br>
&gt; &gt; &gt;&gt;&gt;&gt; Speaking of layers, can you *please* rename meta-yocto to<br>
&gt; &gt; &gt;&gt;&gt;&gt; meta-poky? It&#39;s what it&#39;s actually is and would remove a lot of<br>
&gt; &gt; &gt;&gt;&gt;&gt; confusion when trying to explain that yocto is not a distro, even<br>
&gt; &gt; &gt;&gt;&gt;&gt; if the distro layer is called &#39;meta-yocto&#39;.<br>
&gt; &gt; &gt;&gt;&gt;<br>
&gt; &gt; &gt;&gt;&gt; This is a tangent, but a couple of points:<br>
&gt; &gt; &gt;&gt;&gt;<br>
&gt; &gt; &gt;&gt;&gt; 1) This rename would not come for free. We&#39;d need to update people&#39;s<br>
&gt; &gt; &gt;&gt;&gt; existing bblayers.conf files on the fly, as we did when<br>
&gt; &gt; &gt;&gt;&gt; meta-yocto-bsp was split out of meta-yocto, and thus bump<br>
&gt; &gt; &gt;&gt;&gt; LCONF_VERSION; however, doing this only in poky has resulted in<br>
&gt; &gt; &gt;&gt;&gt; annoying problems when users remove poky from their configurations<br>
&gt; &gt; &gt;&gt;&gt; (since LCONF_VERSION is out-of-step between Poky and OE-Core, leading<br>
&gt; &gt; &gt;&gt;&gt; to confusing errors in this situation). Thus I think we&#39;d want to<br>
&gt; &gt; &gt;&gt;&gt; solve this once and for all by bumping the value in OE-Core as well<br>
&gt; &gt; &gt;&gt;&gt; as Poky.<br>
&gt; &gt; &gt;&gt;&gt;<br>
&gt; &gt; &gt;&gt;&gt; 2) If you propose this rename, perhaps you will also consider<br>
&gt; &gt; &gt;&gt;&gt; renaming meta-oe, since that name within a similarly named<br>
&gt; &gt; &gt;&gt;&gt; meta-openembedded repository leads to a similar level of<br>
&gt; &gt; &gt;&gt;&gt; confusion...?<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; I have no problems with renaming that layer since I get confused by<br>
&gt; &gt; &gt;&gt; this a few times a week myself :)<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; What would we we rename it to?<br>
&gt; &gt;<br>
&gt; &gt; I&#39;m very tempted to suggest &#39;meta-yocto&#39;<br>
&gt;<br>
&gt; I definitely find meta-yocto a better option here. It would save me from<br>
&gt; some confusion when talking about yocto to other people.<br>
<br>
</div></div>I&#39;m not following; meta-yocto is already called meta-yocto ... ? Maybe you<br>
didn&#39;t realise Koen was joking...<br>
<div class="im"><br></div></blockquote><div><br></div><div>Misread that. I thought he was talking about poky. Taking back my stupid statement.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">
&gt; Related to meta-oe, even if that would be a smaller problem, I think<br>
&gt; meta-openembedded is a better name for that layer too.<br>
<br>
</div>That doesn&#39;t solve the problem I was talking about, namely that there&#39;s little<br>
distinction between meta-openembedded the repository (that contains a number<br>
of layers) and meta-oe which is one of those layers. These are two different<br>
things and the similar naming makes it hard to always know which one people<br>
are talking about.</blockquote><div><br></div><div>In that case the collection of layers should be meta-openembedded and the meta-oe layer something like meta-openembedded-common or whatever. </div><div><br></div></div>-- </div>

<div class="gmail_extra"><b style="color:rgb(51,51,51);font-family:Arial;text-align:center">ag</b>
</div></div>