Re: Debian's branches and release model
On Jo, 21 oct 21, 13:00:09, Sam Hartman wrote: > Simon> However, the problem with freezing testing but not freezing > Simon> unstable is that if you do that, all updates to testing > Simon> during the freeze (to fix the release-critical bugs that stop > Simon> it from already being ready for release) have to go into > Simon> testing via testing-proposed-updates, which approximately > Simon> nobody uses. > > Have we ever looked into getting more people to use TPU so it's a viable > path? An idea would be to use[1] and promote it as security support for testing, also outside the freeze, e.g. for the cases where a security relevant update via unstable would take more than one day or so to migrate. This reminds me of this proposal: https://lists.debian.org/debian-devel/2011/05/msg00275.html As far as I recall it also had the codename "bob" (after RollerBob), but I can't find the reference right now. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Debian's branches and release model
Simon> However, the problem with freezing testing but not freezing Simon> unstable is that if you do that, all updates to testing Simon> during the freeze (to fix the release-critical bugs that stop Simon> it from already being ready for release) have to go into Simon> testing via testing-proposed-updates, which approximately Simon> nobody uses. Have we ever looked into getting more people to use TPU so it's a viable path? This issue comes up often enough that it's clear a significant chunk of the community wants it. I understand that it probably would take years to overcome all the obstacles-- I think there are several you didn't mention. But this has been going on for years, so I'm wondering if anyone has been willing to put in effort on things like trying to convince people to test out TPU, or making it easier to run QA/autopkgtest/etc against TPU, etc.
Re: Debian's branches and release model
Thomas Goirand dijo [Wed, Oct 20, 2021 at 10:51:59PM +0200]: > >> That's obviously what I'm doing. But when there's 2 releases during the > >> freeze, it means one of them will never reach Unstable. > > > > Right, which makes perfect sense. > (...) > > I guess very few will, but if it's needed, it's available -- and > > the work for you when the freeze is done is much smaller (just > > re-target changelog, re-build, re-upload). > > > > What do you lose by those uploads not reaching unstable? > > Very simple: an upgrade path. In most OpenStack projects, you cannot > skip an OpenStack release, at least because of the db schema upgrades. Uff, that sounds quite ugly :-( ...And what about providing Openstack packages whose name includes the version, as Linux or PostgreSQL do? that way, if OpenStack releases twice a year and Debian every two years, Debian X can include the four OpenStack releases that have happened since Debian X-1... Or you can continue running your previous OpenStack release if you so want, for some extra years. It would be up to the sysadmin to jump from OpenStack a→b→c→d before upgrading to Debian X+1 (which ships with e, f, g, h). It seems as very little gain for the huge framework that OpenStack is. Now, OTOH, distribution maintainers could work together to pick migrations. If you can pick all the needed bits from the d→e migration and apply them in your postinst (if upgrading from d to f), you can effectively skip going through e. Of course, picking the migrations for every OpenStack release could allow you to build intelligent (although probably obese) maintainer scripts able to perform the needed updates you have, a→d, d→g, etc. I guess I'm just stating obvious bits... and that the OpenStack complexity would make this obviously harder. But if the process is automatizable, it is doable (of course, with enough developer resources). And fleshing out the needed migrations would benefit not only Debian, but every distribution carrying non-consecutive OpenStack packages.
Re: Debian's branches and release model
On 2021-10-21 02:24:19 +0200 (+0200), Thomas Goirand wrote: [...] > What I don't know is how far OpenStack went for supporting > skipping releases. For example, would it work to upgrade from > Rocky (in Buster) to Victoria (in Bullseye) directly? For which > projects? I don't think so, at least not for enough of the projects in OpenStack yet, but that's the sort of thing I'd *like* to try to work toward in the community. There's a desire for it well beyond just the GNU/Linux distributions, lots of folks with deployments would prefer to upgrade every couple of years without having to step through several intermediate versions of everything in order to do so. A big part of the problem is testing though: if we want to continuously test upgrade viability, then the number of possible combinations of start and end versions for those upgrade tests present a significant challenge. -- Jeremy Stanley signature.asc Description: PGP signature
Re: Debian's branches and release model
On 10/21/21 12:29 AM, Jeremy Stanley wrote: > On 2021-10-20 22:51:59 +0200 (+0200), Thomas Goirand wrote: > [...] >> In most OpenStack projects, you cannot skip an OpenStack release, >> at least because of the db schema upgrades. > [...] > > Upstream, I want to keep pushing on what we referred to as > "skip-level upgrades" which would be something akin to embedding > just the routines needed to upgrade data structures for earlier > versions into each later version. The "fast-forward upgrades" we > worked out (where you at least don't need to start any services on > the intermediate versions) is certainly an improvement, but not a > desirable end state in my opinion. > > Granted, from a Debian perspective, this would be akin to upgrading > from buster to bookworm without installing bullseye's packages along > the way. Not as vast a collection of software albeit, but still > hundreds of projects which need upgrading and need to be able to > "skip" between arbitrary numbers of intermediate releases, so not > trivial either. What I don't know is how far OpenStack went for supporting skipping releases. For example, would it work to upgrade from Rocky (in Buster) to Victoria (in Bullseye) directly? For which projects? Cheers, Thomas Goirand
Re: Debian's branches and release model
On 2021-10-20 22:51:59 +0200 (+0200), Thomas Goirand wrote: [...] > In most OpenStack projects, you cannot skip an OpenStack release, > at least because of the db schema upgrades. [...] Upstream, I want to keep pushing on what we referred to as "skip-level upgrades" which would be something akin to embedding just the routines needed to upgrade data structures for earlier versions into each later version. The "fast-forward upgrades" we worked out (where you at least don't need to start any services on the intermediate versions) is certainly an improvement, but not a desirable end state in my opinion. Granted, from a Debian perspective, this would be akin to upgrading from buster to bookworm without installing bullseye's packages along the way. Not as vast a collection of software albeit, but still hundreds of projects which need upgrading and need to be able to "skip" between arbitrary numbers of intermediate releases, so not trivial either. -- Jeremy Stanley signature.asc Description: PGP signature
Re: Debian's branches and release model
On Wed, Oct 20, 2021 at 10:51:59PM +0200, Thomas Goirand wrote: > On 10/20/21 7:50 PM, Gunnar Wolf wrote: > > Thomas Goirand dijo [Wed, Oct 20, 2021 at 09:11:13AM +0200]: > >>> You can upload it to experimental > >> > >> That's obviously what I'm doing. But when there's 2 releases during the > >> freeze, it means one of them will never reach Unstable. > > > > Right, which makes perfect sense. > > > > The group of people interested in having always the latest OpenStack > > will be able to install from your packages in experimental. > > Mostly, OpenStack is consumed using the unofficial backports we provide > through osbpo.debian.net, which contains backports from Jessie to > Bullseye, for 14 OpenStack releases so far. I'd love to make it an > official Debian channel on debian.org, through the official Debian > backports repositories if only I could have 4 or 5 repos per Debian > release. I had hope in 2014 when Ganneff described his vision of > Bikesheds, but it's not happening, unfortunately. > > Consuming OpenStack from Experimental, while probably doable, looks like > not an easy thing to do at least. > > > I guess > > very few will, but if it's needed, it's available -- and the work for > > you when the freeze is done is much smaller (just re-target changelog, > > re-build, re-upload). > > > > What do you lose by those uploads not reaching unstable? > > Very simple: an upgrade path. In most OpenStack projects, you cannot > skip an OpenStack release, at least because of the db schema upgrades. > With something this fast moving, could you treat it like Firefox and just obsolete release -1 each time, marking it as unsuitable for upgrade if you're older? Andy Cater Andy Cater > Cheers, > > Thomas Goirand (zigo) >
Re: Debian's branches and release model
On 10/20/21 7:50 PM, Gunnar Wolf wrote: > Thomas Goirand dijo [Wed, Oct 20, 2021 at 09:11:13AM +0200]: >>> You can upload it to experimental >> >> That's obviously what I'm doing. But when there's 2 releases during the >> freeze, it means one of them will never reach Unstable. > > Right, which makes perfect sense. > > The group of people interested in having always the latest OpenStack > will be able to install from your packages in experimental. Mostly, OpenStack is consumed using the unofficial backports we provide through osbpo.debian.net, which contains backports from Jessie to Bullseye, for 14 OpenStack releases so far. I'd love to make it an official Debian channel on debian.org, through the official Debian backports repositories if only I could have 4 or 5 repos per Debian release. I had hope in 2014 when Ganneff described his vision of Bikesheds, but it's not happening, unfortunately. Consuming OpenStack from Experimental, while probably doable, looks like not an easy thing to do at least. > I guess > very few will, but if it's needed, it's available -- and the work for > you when the freeze is done is much smaller (just re-target changelog, > re-build, re-upload). > > What do you lose by those uploads not reaching unstable? Very simple: an upgrade path. In most OpenStack projects, you cannot skip an OpenStack release, at least because of the db schema upgrades. Cheers, Thomas Goirand (zigo)
Re: Debian's branches and release model
Thomas Goirand dijo [Wed, Oct 20, 2021 at 09:11:13AM +0200]: > > You can upload it to experimental > > That's obviously what I'm doing. But when there's 2 releases during the > freeze, it means one of them will never reach Unstable. Right, which makes perfect sense. The group of people interested in having always the latest OpenStack will be able to install from your packages in experimental. I guess very few will, but if it's needed, it's available -- and the work for you when the freeze is done is much smaller (just re-target changelog, re-build, re-upload). What do you lose by those uploads not reaching unstable?
Re: Debian's branches and release model
On 10/20/21 7:52 AM, Andrey Rahmatullin wrote: > On Wed, Oct 20, 2021 at 02:43:47AM +0200, Thomas Goirand wrote: >>> However, the problem with freezing testing but not freezing unstable is >>> that if you do that, all updates to testing during the freeze (to fix the >>> release-critical bugs that stop it from already being ready for release) >>> have to go into testing via testing-proposed-updates, which approximately >>> nobody uses. >> >> We don't use it, because we're told to use unstable... > It's about using on machines, not about uploading. > >> If we were told that it's ok to upload changes to unstable during the >> freeze, and upload to testing-proposed-updates, we'd do it (and IMO, >> it'd be a very good move from the release team). > The RT position on this was always "nobody uses t-p-u it so please no", as > repeated every freeze when someone asks why we don't do this. > It's a chicken and egg issue. If nobody uploads there, nobody with have any incentive to set it up. Cheers, Thomas Goirand (zigo)
Re: Debian's branches and release model
On 10/20/21 6:47 AM, Mechtilde Stehmann wrote: > Hello, > > > Am 20.10.21 um 02:43 schrieb Thomas Goirand: >> Hi Simon, >> >> For me, the long freeze are very problematic. They may spawn for 6 >> months, which is how long it takes for a new OpenStack release to show >> up, and then I don't know where to upload it... :/ > > You can upload it to experimental That's obviously what I'm doing. But when there's 2 releases during the freeze, it means one of them will never reach Unstable. Cheers, Thomas Goirand (zigo)
Re: Debian's branches and release model
On Wed, Oct 20, 2021 at 02:43:47AM +0200, Thomas Goirand wrote: > > However, the problem with freezing testing but not freezing unstable is > > that if you do that, all updates to testing during the freeze (to fix the > > release-critical bugs that stop it from already being ready for release) > > have to go into testing via testing-proposed-updates, which approximately > > nobody uses. > > We don't use it, because we're told to use unstable... It's about using on machines, not about uploading. > If we were told that it's ok to upload changes to unstable during the > freeze, and upload to testing-proposed-updates, we'd do it (and IMO, > it'd be a very good move from the release team). The RT position on this was always "nobody uses t-p-u it so please no", as repeated every freeze when someone asks why we don't do this. -- WBR, wRAR signature.asc Description: PGP signature
Re: Debian's branches and release model
Hello, Am 20.10.21 um 02:43 schrieb Thomas Goirand: > Hi Simon, > > For me, the long freeze are very problematic. They may spawn for 6 > months, which is how long it takes for a new OpenStack release to show > up, and then I don't know where to upload it... :/ You can upload it to experimental > > As a result, the Wallaby release of OpenStack (released last spring) > never had the time to migrate fully to testing, for example, because I > uploaded Xena (released last October). > > Anyways, here's my reply inline below... > > On 10/18/21 6:54 PM, Simon McVittie wrote: >> It >> also aligns the incentives for enough people to make sure that we can >> successfully make a release in a finite time - even developers who >> don't really care about releases and just want the latest versions >> are incentivized to fix enough things to make the next release happen, >> so that the freeze will end and they can get back to uploading the >> latest versions to unstable. > > I don't know how you can make sure that using testing-proposed-updates > instead of unstable would suddenly demotivate everyone that cares about > about next stable. Could you explain? > > On 10/18/21 6:54 PM, Simon McVittie wrote: >> However, the problem with freezing testing but not freezing unstable is >> that if you do that, all updates to testing during the freeze (to fix the >> release-critical bugs that stop it from already being ready for release) >> have to go into testing via testing-proposed-updates, which approximately >> nobody uses. > > We don't use it, because we're told to use unstable... > > If we were told that it's ok to upload changes to unstable during the > freeze, and upload to testing-proposed-updates, we'd do it (and IMO, > it'd be a very good move from the release team). > >> Having code changes for our next stable release be essentially untested >> is not great from a QA perspective - if nobody is trying out those new >> versions except for their maintainer, then nobody can find and report the >> (potentially serious) bugs that only happen in system configurations that >> differ from the maintainer's system. That's why the release team strongly >> discourages packages going into testing via testing-proposed-updates, and >> encourages packages going into testing via unstable. > > If we were, during the freeze, directed to upload fixes to > testing-proposed-updates, then there would be more people adding it to > their sources.list during the freeze. > > Cheers, > > Thomas Goirand (zigo) > -- Mechtilde Stehmann ## Debian Developer ## PGP encryption welcome ## F0E3 7F3D C87A 4998 2899 39E7 F287 7BBA 141A AD7F
Re: Debian's branches and release model
Hi Simon, For me, the long freeze are very problematic. They may spawn for 6 months, which is how long it takes for a new OpenStack release to show up, and then I don't know where to upload it... :/ As a result, the Wallaby release of OpenStack (released last spring) never had the time to migrate fully to testing, for example, because I uploaded Xena (released last October). Anyways, here's my reply inline below... On 10/18/21 6:54 PM, Simon McVittie wrote: > It > also aligns the incentives for enough people to make sure that we can > successfully make a release in a finite time - even developers who > don't really care about releases and just want the latest versions > are incentivized to fix enough things to make the next release happen, > so that the freeze will end and they can get back to uploading the > latest versions to unstable. I don't know how you can make sure that using testing-proposed-updates instead of unstable would suddenly demotivate everyone that cares about about next stable. Could you explain? On 10/18/21 6:54 PM, Simon McVittie wrote: > However, the problem with freezing testing but not freezing unstable is > that if you do that, all updates to testing during the freeze (to fix the > release-critical bugs that stop it from already being ready for release) > have to go into testing via testing-proposed-updates, which approximately > nobody uses. We don't use it, because we're told to use unstable... If we were told that it's ok to upload changes to unstable during the freeze, and upload to testing-proposed-updates, we'd do it (and IMO, it'd be a very good move from the release team). > Having code changes for our next stable release be essentially untested > is not great from a QA perspective - if nobody is trying out those new > versions except for their maintainer, then nobody can find and report the > (potentially serious) bugs that only happen in system configurations that > differ from the maintainer's system. That's why the release team strongly > discourages packages going into testing via testing-proposed-updates, and > encourages packages going into testing via unstable. If we were, during the freeze, directed to upload fixes to testing-proposed-updates, then there would be more people adding it to their sources.list during the freeze. Cheers, Thomas Goirand (zigo)
Re: Debian's branches and release model
> > https://wiki.debian.org/ReleaseProposals > Great list, contains a lot of what I have to say. The fact that debian is laser focused on stable, and does not officially encourage using testing as a rolling release (as evidenced from a couple replies to this email chain), yet there are still people doing it, is a testament of how good debian is. Just don't abandon us:) If testing is part of QA, then popularizing it should benefit. Staying closer to upstream releases gets my vote. Quote from the page, "Looks like it's time for action! Somebody (maybe the Debian project leader) should pick up the hot potato and compile a list of the proposals which are going to be adopted. Flame wars ensue. Then Debian emerges renewed, as a phoenix from the ashes." cheers, P
Re: Debian's branches and release model
On Mon, 18 Oct 2021 at 12:29:55 -0400, Peter Hoist wrote: > So the question is, why not cut a release branch every two years, and at the > same time keep the unstable/testing alive? We have this conversation about once a year. Essentially, the freeze makes sure that the versions we are proposing to put in the next stable get as much testing from our developers and prerelease users as possible. It also aligns the incentives for enough people to make sure that we can successfully make a release in a finite time - even developers who don't really care about releases and just want the latest versions are incentivized to fix enough things to make the next release happen, so that the freeze will end and they can get back to uploading the latest versions to unstable. The purpose of the testing distribution is exactly that it is what will be the next stable, so by definition it is not possible to freeze the next stable without freezing testing. We could invent a new suite, for which the name "rolling" has been proposed in the past, and keep updating unstable and "rolling", while continuing to freeze "testing". However, the problem with freezing testing but not freezing unstable is that if you do that, all updates to testing during the freeze (to fix the release-critical bugs that stop it from already being ready for release) have to go into testing via testing-proposed-updates, which approximately nobody uses. Having code changes for our next stable release be essentially untested is not great from a QA perspective - if nobody is trying out those new versions except for their maintainer, then nobody can find and report the (potentially serious) bugs that only happen in system configurations that differ from the maintainer's system. That's why the release team strongly discourages packages going into testing via testing-proposed-updates, and encourages packages going into testing via unstable. Before the "testing" suite was invented in 2000, we *did* freeze the "next release" branch without freezing unstable - you can see this in very old packages' changelogs, with packages that were uploaded to "frozen", or to both "frozen" and "unstable". Information about that from around the time "testing" was implemented: https://lists.debian.org/debian-devel/2000/08/msg00906.html smcv
