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. > 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 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. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1083): https://lists.openembedded.org/g/openembedded-architecture/message/1083 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]] -=-=-=-=-=-=-=-=-=-=-=-
