On Tue, 26 May 2020 at 18:13, Richard Purdie <[email protected]> wrote: > > On Tue, 2020-05-26 at 17:46 +0100, Paul Barker wrote: > > I've re-read the policy on LTS backports / mixin repositories > > ( > > https://wiki.yoctoproject.org/wiki/LTS#LTS_.E2.80.9CMixin.E2.80.9D_repositories > > ) > > and have a few thoughts. > > > > I don't think `oecore-backport-mixin` is a good name for two reasons. > > One is that we're introducing the new concept of "mixins" when these > > really would just be normal layers and I think new terminology would > > be potentially confusing. > > You can argue this both ways. I think these *should* be differentiated > from "normal" layers in that they're specific shims designed with one > specific purpose for one specific LTS. I'm not 100% sure the name is > right but I do think they should have some "branding" to make them a > little different so people recognise them for what they are.
I don't want to bikeshed too much on the name. Once we start using it we'll get used to it anyway. > > > The second is that we may also want > > backports for things which exist in the meta-openembedded repository > > (let's say a new Postgresql version as an example). I propose we > > instead just call this `openembedded-backports`. > > We're going to take "backports" or "mixins" for *any* layer in there? > I'd expect meta-openembedded would want its own location for these and > grouping "core mixins" together would make most logical sense? I suppose it depends how many things people want to backport. If it's only a few overall then one repository would be fine but I guess focusing just on oe-core here does prevent it from becoming a sprawling mess. > > > I don't think the branching policy is ideal either. I'm not a fan of > > having unrelated code on different branches within the same > > repository. I think the backports repository should follow a similar > > layout to meta-openembedded where each small backport layer is a > > top-level directory within this repository and we'd just have a > > single `dunfell` branch in git for now. > > I do understand that concern, equally, I also want to encourage small > and specific layers with maintainers who can respond and work > effectively. With this model I worry we'd end up with a single > "backports" maintainer who was expected to handle almost anything. > > This will also encourage people to add "everything" in the checkout and > make it too easy for people to pull everything (creating potentially > messy inter-dependencies) when we really want people to have the > impression they should only ever be doing this if they really have to. > > I don't think what is in the LTS policy is perfect, far from it, but > there were reasons for those choices and I do have significant worries > about the alternatives you propose. I'm not sure if there is some other > solution which could address those concerns... > > I do want to be clear that the mixins are supposed to be an exception, > not a general rule whenever someone wants some new version. If we > create too many of them we totally undermine the value of the LTS. Those are very good points. I think different branches being different mixin layers does make things a bit difficult and may cause complications when using kas, repo or some other tool to manage the layers used by a project. That's my main technical concern here. The only available options to separate the layers are different branches, different directories or entirely different repositories (unless I'm forgetting something). Of those I can see problems with using different branches in the same repo but the others are fine to me. Thanks, -- Paul Barker Konsulko Group
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1084): https://lists.openembedded.org/g/openembedded-architecture/message/1084 Mute This Topic: https://lists.openembedded.org/mt/74481727/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
