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 > > > -- _______________________________________________ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
