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

[Martin Jansa]

On Sat, Sep 03, 2016 at 12:04:26PM +0100, Richard Purdie wrote:
> On Sat, 2016-09-03 at 12:14 +0200, Martin Jansa wrote:
> > My only 3 "naming" issues are:
> > 1) The next release codename is decided only shortly before the
> > actual release
> > 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.
> > 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).
> > Knowing the codename of next release in advance (announced together
> > with current release) would be very helpful for us.
> 
> This is good feedback. I'd not considered it in those terms and there
> is no reason we can't announce the release names further in advance. I
> will admit I haven't actually decided on what 2.2 will be called but
> that doesn't mean I can't get a move on with these! :)
> 
> > 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.
> > I haven't read the documentation recently, but to avoid this
> > confusion it should mention that to get release x.y you can
> > a) download tarball (not recommended)
> > b) clone poky repository, release codename branch
> > c) achieve _the same thing_ by cloning these 5 repositories (release
> > codename branch and for bitbake x.xx branch)
> > and the same information should be in poky's README file.
> 
> I can't remember where I've talked about it now but I do have a
> visualisation I'd love to see displayed on the YP website which
> consists of circles representing bitbake, OE-Core, meta-yocto, docs,
> pseudo and other components and shows how they intersect. A diagram
> like that would perhaps also help people understand the relationship
> between these things.
> 
> I do also think a docs review by the core people of the projects might
> be in order. Its been a while since I had time to spend on docs and I
> think some subtle restructuring and making certain things clearer could
> help. I'm struggling a lot to find time to do some of these kinds of
> things at the moment and keep up to the day to day flow of
> patches/testing/review. I do also want to have a "Yocto Project
> Compatible v2" programme which would hopefully address some of the
> issues currently there, make it more attractive and also improve
> quality at the same time.
> 
> Do you collectively think we might be able to all free up say a week of
> time and all concentrate together on improving the docs (be it OE/YP
> websites, YP docs, OE/YP wiki etc)?
> 
> > 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.
> 
> That is true. I'd love to have some kind of standardised tooling we
> could all agree to use in this area, I did start a discussion about
> that. Sadly there were strong opinions which I couldn't see any good
> way to reconcile so I still don't know how to proceed on this one.
> 
> > 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
> > 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.
> 
> I do understand, however playing devil's advocate to explore the
> problem, let me ask a question. Would this information make a
> difference to your answer?

Not very often, but sometimes yes.

I remember good example e.g. when conf/distro/include/no-static-libs.inc
was added and enabled by default in poky DISTRO first.

I haven't found the exact IRC log, but it went like this:

A) Hi, have you seen qtbase failing with error about --disable-static?
B) yes, I have it's most likely caused by no-static-libs.inc, did you
   add it to your distro config?
A) I haven't changed anything
B) Are you using poky distro?
A) No I've my own clone of Yocto and oe-core, I've downloaded it from
   git://git.yoctoproject.org/meta-yocto
B) That doesn't answer my question, are you using poky as a DISTRO in
   your builds?
A) How to check? I see these directories:
   meta-yocto, meta, bitbake, meta-qt5

Yes, I should have stop here with RTFM message, but maybe the developer
asking for help wouldn't be so confused and we would resolve it much
quicker if we have less ambiguous terminology.

And yes he was using poky as a DISTRO and had no-static-libs.inc
included after he updated meta-yocto repository with meta-poky layer.

Regards,

> I appreciate in some cases it does, I also suspect in some cases it
> might not.
> 
> I suspect most people "using poky" mean they have the poky git repo and
> whether or they set the DISTRO="poky" or not doesn't make that much
> difference due to the close alignment with nodistro.
> 
> Cheers,
> 
> Richard
> 

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-architecture/attachments/20160905/d2c18a7b/attachment-0002.sig>