Re: Splitting meta-oe?

[Khem Raj <raj.khem@gmail.com>]

On 2/20/18 9:46 AM, Richard Purdie wrote:
> Repositories have reputations. OE-Core is fairly heavily curated and
> tested and has certain "guarantees" about what people can expect to
> work. The meta-oe repo is a little trickier as the different pieces do
> have different 'SLA's (service level agreements). Some pieces like
> meta-networking/meta-python likely build well, other pieces like some
> of the bitrotting pieces of the meta-oe layer probably don't build in
> as many different configurations/architectures and on balance may be
> more likely to hit issues.
> 
> I think the world may need to change a bit. We should probably change:
> 
> * The way people get started with the Yocto Project and Poky
>   to move away from the combo repo and into specific layers.
> * to have YP testing more layers as part of its builds and testing
> * to make it easier for people to establish an SLA type reputation for 
>   a layer.
> 
> Part of this is a need for a more universal "using OE" later setup
> tooling. I've wanted to work on that for a while and I will get there
> but if I spend time on it, I want to get it right. I've not had enough
> time to get it right (as yet).
> 
> Part of this means redefining poky, the YP autobuilders and so on.
> Pieces of the autobuilder work are in process and will lead to wider
> layer testing.
> 
> I have strong influence over the above so I can likely make those
> happen, time constraints aside. One piece I need the help of others
> with is meta-oe (the repo).
> 
> Even just splitting meta-oe out from meta-oe might be enough to
> establish the SLA differences, I don't know.

this is short term panacea, few years later we will again talk about
meta-oe in same sense because it would have caught the packages which
belong to no other specific layers and cant be in oe-core

unless there is a solution for meta-oe layer, it seems to be like we are
just changing maintainer control structure for repos.

> 
> There is a question about what problem would this solve. The move from
> OE-Classic was partly about defining maintainership and processes for
> recipes which we do with layers. The pieces in the separate layers have
> now become the things we set out to create but the catchall of meta-oe
> (the layer) remains. I do think we should still be aiming to filter
> meta-oe into distinct layers with distinct maintainership. There will
> always be some "leftovers" in a catchall but I think it does have a
> different personality to the other well separated components and we
> need to show to users that they do have different expectations from
> them.

in practical downstream projects for real products, we include almost
all layers, so from that perspective it just is another hassle for
integrating.

> 
> I hope I'm managing to convey this concept ok, I'm really trying to
> take a step back here and think what will help OE users and the project
> and where we need to go with things. I'm not saying we should/shouldn't
> do this for 100% certain, I do want people to think about the
> alternatives though and what options may be possible.
> 

I dont disagee here. but it would be nicer if we had a restructuring
plan for layers within repo

> Cheers,
> 
> Richard
> 
> 
>