Re: Layer model doomed, unless we all work together

[Joe MacDonald <Joe_MacDonald@mentor.com>]

[-- Attachment #1: Type: text/plain, Size: 5295 bytes --]

Hi Paul,

[Re: [yocto] Layer model doomed, unless we all work together] On 14.11.20 (Thu 13:43) Paul Eggleton wrote:

> On Wednesday 19 November 2014 22:34:41 Joe MacDonald wrote:
> > [[yocto] Layer model doomed, unless we all work together] On 14.11.18 (Tue 
> 16:28) Philip Balister wrote:
> > > I see a couple of issues we need to start talking about:
> > > 
> > > 1) recipes that need to move closer to core because a range of other
> > > packages use them.
> > 
> > This was actually the only thing I thought needed further discussion
> > (everything else should largely be a nod-in-agreement thing), as in some
> > cases I'm not sure it's always clear what constitutes "closer to the
> > core".  Poky and oe-core layers are pretty clear, but the next step
> > beyond that isn't.  Are all layers hosted on git.yoctoproject.org
> > inherhently "more core" than layers on git.openenbedded.org?  And
> > there's a number of shells when you start including all of the github
> > projects, setting aside other open-source project hosting services.
> 
> The answer to me there is certainly not. I've said this recently in other 
> discussions, but I'll say it here anyway in case anyone else isn't sure - 
> layers on git.yoctoproject.org should not be considered in any way more official 
> than anywhere else solely based on them being hosted there. Anyone who wants 
> to maintain and publish a layer suitable for others to use can get a 
> repository on git.yoctoproject.org - there's no official review, validation, or 
> acceptance criteria in the general case just for having a repository there 
> (beyond being related to the project, that is).

That certainly makes sense to me, though I can respect if a project
maintainer wanted to try to keep everything they put there contained to
other projects hosted there.  Probably that's not even the case now,
I've not looked, but if I were starting a layer that I wanted to be
dependent only on, say, oe-core, and it was still useful to the
community at large, I would consider git.yoctoproject.org to be the most
sensible place to host it.

Regardless, I think your clarification makes perfect sense.

> To me this isn't so much about "closer to the core", it's about:
> 
>  1) sensible recipe groupings, e.g. meta-networking rather than a particular 
> project's mixed recipes layer
> 
>  2) good maintenance, i.e. recipes are semi-regularly updated when upstream 
> releases happen, fixed when needed to accommodate changes that happen in other 
> layers it depends upon such as OE-Core, and the maintainer is reasonably 
> responsive to patches or questions relating to the layer.
> 
> We need both of those things to encourage re-use, and if we have both then it 
> doesn't really matter where a layer is hosted as long as it's listed in the 
> layer index.

Fair enough.  Though I do think that a natural consequence of the
groupings in #1 above would tend to have recipes that appear in multiple
project's mixed recipe layers move toward the core.  But I also agree
that it needs to make sense for the layers involved.

> > Looking at the link you sent out based on Paul's suggestion, I see I'm
> > actually on both sides of this equation, so yay!  And I'll limit the
> > discussion to what's indexed there.
> > 
> > Here're my examples.
> > 
> > iscsi-initiator-utils: both in meta-networking nd meta-openstack.  Both
> > at the same version currently but wildly different contents.
> > meta-openstack is a git.yoctoproject.org project, so does that make it
> > closer to the core?  I would think not, but as I recall there had been
> > some comment about the openstack layer intending to limit layer
> > dependencies outside Yocto core when it first appeared, so maybe making
> > meta-networking a dependency is a non-starter for them.
> 
> So I've talked to Bruce about meta-openstack before, with particular regard to 
> the number of python recipes that the layer ships and future overlap with 
> meta-python, and apparently the policy there is not to pull in other layers 
> for some dependencies with the aim of avoiding breakage on upgrades. I don't 
> like that very much at all, to be frank, but I can at least understand it 
> given how huge OpenStack is. It does of course mean that the overlap with that 
> layer in particular is only going to increase as time goes on.

Hmm.  Okay, I don't want to veer too far off the topic, but what I'm
getting from this is that meta-openstack is a layer usable for building
OpenStack, but otherwise probably isn't an ideal base for other layers.
There's two obvious points of divergence between meta-networking recipes
and meta-openstack ones, both of which have the same priority, and it
sounds like there's going to be an increasing number of these with
meta-python.  I don't know that, given how large OpenStack is, adding
other layer dependencies would amount to more than a drop in the bucket,
but as a philosophical discussion rather than a technical one, I'll
stick to knowing to regularly check the index and time I'm looking at
recipes or working with a new layer.  That's probably really good advice
for anyone, honestly.

That's for the info, Paul.

-- 
-Joe MacDonald.
:wq

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 501 bytes --]