<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">During the latest OEDAM meeting, following ELC2016 in San Diego, a discussion</div>began regarding Yocto/OE "branding" as well as how confusing it is for newbies<br class="">to understand all the terminology. Since this discussion was taking too much<br class="">time away from the OEDAM, interested people gathered at lunch to continue the<br class="">conversation. What follows is what was discussed at the naming table at OEDAM.<br class=""><br class="">The problem is that the messaging and branding surrounding Yocto/Poky/OE is<br class="">confusing for everyone... sometimes even those directly involved in these<br class="">projects! Explaining the distinctions between all these terms is convoluted<br class="">and confusing. The ultimate users of all these things mostly don't care: they<br class="">just want to use "yocto" (whatever that is) and build their product. Most<br class="">people still don't understand the differences and just randomly piece together<br class="">"Yocto/OE/Poky/distribution/build system/tool" and hope they get it right when<br class="">asking questions.<br class=""><br class="">Minimally, explaining that the Yocto Project Release 2.0 (Jethro) is in fact<br class="">Poky version 14.0, or that you can get a git version of the Yocto Project by<br class="">cloning poky.git is just dizzying.<br class=""><br class="">The technologies in question are powerful, capable and complex, but they<br class="">should not be this hard to explain to others! OSVs, for example, not only have<br class="">to explain all of this to customers, they also have to explain the<br class="">relationship between OE/Yocto and their products. All these things should be<br class="">able to be explained in simple language.<br class=""><br class="">Many of the terms (such as "distribution" and "poky" itself) are not only<br class="">overloaded, their definitions have changed over time. Also there is a lot of<br class="">confusion surrounding the use of "meta-foo" to both refer to the layer name<br class="">within a release, or the git repo from which it was originally pulled. Again,<br class="">an important distinction, but also something which most people don't care<br class="">about nor appreciate.<br class=""><br class="">This discussion was meant to be the start of a conversation (and not yet solve<br class="">all these problems). The following agreements, and resulting recommendations<br class="">were made.<br class=""><br class="">Agreements:<br class=""><br class="">1) There is a problem with naming/messaging/branding<br class=""><br class="">2) There is minimally a problem with the naming of the git repo and Yocto<br class="">Project release<br class=""><br class="">After discussing a number of possible options the following recommendations<br class="">were agreed upon:<br class=""><br class="">1) Rename the git repo to "yocto-toolbox.git"<br class=""> - The toolbox contains a snapshot of OE-core (and bitbake)<br class=""> - The toolbox contains a distribution layer (meta-poky)<br class=""> - The toolbox could contain more than one distribution layer<br class=""> - The toolbox contains further scripts and tools added by the Yocto Project<br class=""> - The toolbox contains documentation for all these things<br class=""> - Not all the tools in this toolbox need be used<br class=""> - Tools in this tool box could be replaced or omitted by OSVs<br class=""> - Further tools could be added by the end-user* or OSV <br class=""><br class="">* (in this case the end-user are the engineers using a Yocto Project release to<br class=""> build something)<br class=""><br class="">2) Rename release tarball to "yocto-toolbox-<version>.tar.xz"<br class=""> - This makes it consistent with recommendation #1, and decouples it from the<br class=""> Poky release number which is mostly superfluous.<br class=""> - Determining the version of poky could easily be provided in a meta-poky<br class=""> conf file or by a tool<br class=""><br class="">(Alternatively, instead of "toolbox" we could call it "kitchen" to keep with<br class="">the cooking theme. :) )<br class=""><br class="">There are plenty of examples of a project release containing snapshots of<br class="">another project:<br class="">- Debian includes specific releases of gcc/glibc/bash/etc, but we still call it<br class=""> "Debian"<br class="">- OpenDaylight contains a release of OpenStack, but we still call it<br class=""> “OpenDaylight"<div class=""><br class=""></div><div class="">Behan</div><div class=""><br class=""><div class="">
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; " class=""><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; " class=""><div class="">--</div><div class="">Behan Webster</div><div class=""><a href="mailto:behanw@converseincode.com" class="">behanw@converseincode.com</a></div><div class=""><br class=""></div></div><br class="Apple-interchange-newline"></div><br class="Apple-interchange-newline"><br class="Apple-interchange-newline">
</div>
<br class=""></div></body></html>