Re: [gentoo-portage-dev] [RFC] LTS branch of Portage
In all fairness, there haven't been that much incidents with Portage in the past under Zac's supervision, isn't it a bit overkill to bureaucratise the release model just after one incident? It appears to me that changes to Portage need to be considered very carefully, always, since it affects everyone. Thanks, Fabian On 05-10-2021 10:31:40 +0200, Michał Górny wrote: > Hi, everyone. > > I've been thinking about this for some time already, and the recent > FILESDIR mess seems to confirm it: I'd like to start a more stable LTS > branch of Portage. > > Roughly, the idea is that: > > - master becomes 3.1.x, and primary development happens there > > - 3.0.x becomes the LTS branch and only major bugfixes are backported > there > > As things settle down in the future, master would become 3.2.x, 3.1.x > would become LTS, 3.0.x will be discontinued and so on. > > WDYT? > > -- > Best regards, > Michał Górny > > > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [RFC] LTS branch of Portage
On Tue, 2021-10-05 at 10:31 +0200, Michał Górny wrote: > Hi, everyone. > > I've been thinking about this for some time already, and the recent > FILESDIR mess seems to confirm it: I'd like to start a more stable LTS > branch of Portage. > I think this is healthy for most software projects, but two things stand out to me for portage specifically: 1. Most portage users can fake this already by telling portage to accept only stable keywords for sys-apps/portage. I know it's not exactly the same, but it provides many of the same benefits. 2. What happens to the LTS branch when the next EAPI is released?
Re: [gentoo-portage-dev] [RFC] LTS branch of Portage
On Tue, 2021-10-05 at 10:15 -0400, Michael Orlitzky wrote: > On Tue, 2021-10-05 at 10:31 +0200, Michał Górny wrote: > > Hi, everyone. > > > > I've been thinking about this for some time already, and the recent > > FILESDIR mess seems to confirm it: I'd like to start a more stable LTS > > branch of Portage. > > > > I think this is healthy for most software projects, but two things > stand out to me for portage specifically: > > 1. Most portage users can fake this already by telling portage to > accept only stable keywords for sys-apps/portage. I know it's not > exactly the same, but it provides many of the same benefits. That's not going to be possible long-term when I start making more changes ;-). > 2. What happens to the LTS branch when the next EAPI is released? > I haven't really thought about it. Are you suggesting that we could bump 'master' Portage to newer EAPI earlier or...? -- Best regards, Michał Górny
Re: [gentoo-portage-dev] [RFC] LTS branch of Portage
On Tue, 2021-10-05 at 17:13 +0200, Michał Górny wrote: > > > 2. What happens to the LTS branch when the next EAPI is released? > > > > I haven't really thought about it. Are you suggesting that we could > bump 'master' Portage to newer EAPI earlier or...? > I just mean that, a priori, the LTS branch won't be able to install ebuilds that use the next EAPI. Backporting an entire EAPI doesn't seem appropriate for a stable series; but maintaining an increasingly- obsolete branch at that point doesn't make much sense either.
Re: [gentoo-portage-dev] [RFC] LTS branch of Portage
On Tue, 2021-10-05 at 13:16 -0400, Michael Orlitzky wrote: > On Tue, 2021-10-05 at 17:13 +0200, Michał Górny wrote: > > > > > 2. What happens to the LTS branch when the next EAPI is released? > > > > > > > I haven't really thought about it. Are you suggesting that we could > > bump 'master' Portage to newer EAPI earlier or...? > > > > I just mean that, a priori, the LTS branch won't be able to install > ebuilds that use the next EAPI. Backporting an entire EAPI doesn't seem > appropriate for a stable series; but maintaining an increasingly- > obsolete branch at that point doesn't make much sense either. Ah, that makes sense. Indeed, I suppose a new EAPI will be a good point of switching master to LTS. -- Best regards, Michał Górny
Re: [gentoo-portage-dev] [RFC] LTS branch of Portage
On Tue, Oct 5, 2021 at 1:31 AM Michał Górny wrote: > > Hi, everyone. > > I've been thinking about this for some time already, and the recent > FILESDIR mess seems to confirm it: I'd like to start a more stable LTS > branch of Portage. > > Roughly, the idea is that: > > - master becomes 3.1.x, and primary development happens there > > - 3.0.x becomes the LTS branch and only major bugfixes are backported > there > > As things settle down in the future, master would become 3.2.x, 3.1.x > would become LTS, 3.0.x will be discontinued and so on. I'd appreciate a brief overview of how we would expect users to install each branch. E.g. one way might be: sys-apps/portage- # dev branch sys-apps/portage-3.1.x # LTS branch sys-apps/portage-3.0.x # old branch; unmaintained -A > > WDYT? > > -- > Best regards, > Michał Górny > > >
Re: [gentoo-portage-dev] [RFC] LTS branch of Portage
Il giorno mar 5 ott 2021 alle ore 10:31 Michał Górny ha scritto: > Hi, everyone. > > I've been thinking about this for some time already, and the recent > FILESDIR mess seems to confirm it: I'd like to start a more stable LTS > branch of Portage. > > Roughly, the idea is that: > > - master becomes 3.1.x, and primary development happens there > > - 3.0.x becomes the LTS branch and only major bugfixes are backported > there > > As things settle down in the future, master would become 3.2.x, 3.1.x > would become LTS, 3.0.x will be discontinued and so on. > > WDYT? > Sorry but portage is too strictly related to the ebuilds in tree, recent removal of EAPI=5 from most eclasses underlined that. Or to put id differently if you want a LTS portage you also need a certain number of "protected" eclasses and ebuilds It seems a lot of (very appreciated but don't count on me) work > > -- > Best regards, > Michał Górny > > > >
Re: [gentoo-portage-dev] [RFC] LTS branch of Portage
On Mon, Oct 18, 2021 at 4:25 PM Francesco Riosa wrote: > > > Il giorno mar 5 ott 2021 alle ore 10:31 Michał Górny ha > scritto: >> >> Hi, everyone. >> >> I've been thinking about this for some time already, and the recent >> FILESDIR mess seems to confirm it: I'd like to start a more stable LTS >> branch of Portage. >> >> Roughly, the idea is that: >> >> - master becomes 3.1.x, and primary development happens there >> >> - 3.0.x becomes the LTS branch and only major bugfixes are backported >> there >> >> As things settle down in the future, master would become 3.2.x, 3.1.x >> would become LTS, 3.0.x will be discontinued and so on. >> >> WDYT? > > > Sorry but portage is too strictly related to the ebuilds in tree, recent > removal of EAPI=5 from most eclasses underlined that. > Or to put id differently if you want a LTS portage you also need a certain > number of "protected" eclasses and ebuilds > It seems a lot of (very appreciated but don't count on me) work I think this is backwards a bit. The idea is to backport things from the main (development) branch to the LTS branch such that the tree continues to work for both; no? This seems mostly related to "what is a bugfix and will be backported into LTS" and "what is a feature and is not backportable for LTS" in terms of what the tree will rely on. -A > > >> >> >> -- >> Best regards, >> Michał Górny >> >> >>
Re: [gentoo-portage-dev] [RFC] LTS branch of Portage
> On 19 Oct 2021, at 00:24, Francesco Riosa wrote: > > Sorry but portage is too strictly related to the ebuilds in tree, recent > removal of EAPI=5 from most eclasses underlined that. > Or to put id differently if you want a LTS portage you also need a certain > number of "protected" eclasses and ebuilds > It seems a lot of (very appreciated but don't count on me) work FWIW, I don't think it'd be a big deal to just agree that we wouldn't rip out old EAPI support from eclasses and also slow down with adopting new EAPIs for ebuilds (which there's vague consensus about wrt EAPI 8 being done a bit too quickly anyway). i.e. I don't think this is really a blocker. Best, sam signature.asc Description: Message signed with OpenPGP
