[Openembedded-architecture] Notes from the OEDAM "Naming Table"

[Behan Webster]

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

Since OEDEM is fast approaching it would be good to get a discussion 
going on this topic, so it can be addressed properly in Berlin.

Naming is important and the current names are problematic outside of 
this community.

Behan

-- 
Behan Webster
behanw at converseincode.com