<div dir="ltr"><div>Hello,</div><div><br></div>In my experience people are less confused by Poky release numbers (thanks RP for eradicating them where possible) and Yocto Project release numbers are actually doing good job for sorting the codenames and it's something people outside these projects understand.<div><br></div><div>My only 3 "naming" issues are:</div><div>1) The next release codename is decided only shortly before the actual release</div><div>When I need to talk with management about plans for upgrading our builds to Yocto 2.2 release I'll probably reference it as "Yocto 2.2 (master)" while other releases are referenced as Yocto x.x (codename) - even worse when some internal things still have reference to "Yocto 1.7 (master)", because they were created before Dizzy was released and cannot be updated later.</div><div>So in some parts it's easier to use numbers which should be known in advance (darn that mysterious 1.9 release which is still referenced internally and also on Yocto Project wiki pages).</div><div>Knowing the codename of next release in advance (announced together with current release) would be very helpful for us.</div><div><br></div><div>2) People saying they are using poky or yocto or oe-core or OE and not understanding that by these 4 words they in 99% mean the same thing.</div><div>I haven't read the documentation recently, but to avoid this confusion it should mention that to get release x.y you can</div><div>a) download tarball (not recommended)</div><div>b) clone poky repository, release codename branch</div><div>c) achieve _the same thing_ by cloning these 5 repositories (release codename branch and for bitbake x.xx branch)</div><div>and the same information should be in poky's README file.</div><div>Using some other tooling for poky than combo-layer could help (e.g. by seeing the actual repositories as submodules or in some config like for layerman, repo, whatever) - but that's for people actually updating poky repository to decide - I'm just saying that combo-layer does it's job too well abstracting the user from the original repositories.</div><div><br></div><div>3) confusion between poky as a DISTRO or as a git repository, "meta-oe" as a git repository or one of the layers in this git repository</div><div>If I see question about how to achieve something with poky, I never know if he means _the same thing_ as mentioned in 2) or if he is asking specifically how to do something with poky as a DISTRO - this is IMHO common source of additional questions which lead to more confusion.</div><div><br></div><div>Regards,</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Sep 3, 2016 at 10:39 AM, Richard Purdie <span dir="ltr"><<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, 2016-09-02 at 23:04 +0100, Phil Blundell wrote:<br>
> On Fri, 2016-09-02 at 11:44 -0700, Behan Webster wrote:<br>
> > I can't stress enough that this is not a small issue. It is<br>
> > probably the<br>
> > most frustrating non-technical thing people complain to me about<br>
> > using YP.<br>
><br>
> Without wishing to appear harsh, it sounds to me as though your<br>
> complaints are mostly if not entirely political/administrative issues<br>
> around how Yocto names its products and their components. It's not<br>
> obvious to me that there is anything much that the broader OE<br>
> community<br>
> can do to help. If your complaints are with Yocto then I think they<br>
> would be better addressed to one of the Yocto mailing lists.<br>
><br>
> If you do think that there is something that OE (outside Yocto) ought<br>
> to be doing differently then maybe it would be helpful if you could<br>
> provide a separate concise summary of what that is.<br>
<br>
</span>Whilst I can see your point, I do think this is a reasonable discussion<br>
to have here and the issues aren't totally unrelated to OE.<br>
<br>
The branch naming convention for example is something which makes sense<br>
to have in OE and YP layers as a standard to enable interoperability.<br>
There does appear to be confusion about why we have the release<br>
codenames in the first place and I do think that is something we should<br>
try and clear up regardless of the forum.<br>
<br>
There is also feedback, for example about the website which the OE YP<br>
representatives may give back to the Yocto Project advisory board (not<br>
that they don't know my opinion already).<br>
<br>
Cheers,<br>
<br>
Richard<br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
Openembedded-architecture mailing list<br>
<a href="mailto:Openembedded-architecture@lists.openembedded.org">Openembedded-architecture@<wbr>lists.openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-architecture" rel="noreferrer" target="_blank">http://lists.openembedded.org/<wbr>mailman/listinfo/openembedded-<wbr>architecture</a><br>
</div></div></blockquote></div><br></div>