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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.user

Hi,

I am enjoying Debian's testing branch as a reasonably stable and up-to-date 'rolling' release, and I have to say it satisfies all my desires, almost.
The one thing that bothers me is that every two years, the unstable/testing branches are frozen to certain extent because of the stable releases. This means the testing branch can be quite lagged behind upstream releases. One example is gcc, with gcc-11 released almost 6 months ago, and it is still
not default in debian testing - I know it is being worked on right now and probably only a couple days away, but still...

So the question is, why not cut a release branch every two years, and at
the same time keep the unstable/testing alive? Is it because debian
developers think it's too much work to reconcile the differences later, so
they prefer freezing?

Some ppl recommend arch for this reason, but I am already familiar with
apt's way of things, and would hold off switching before I have a better understanding of the bigger picture.

I am certainly not qualified to make recommendations here, just wondering
what is the reason behind it and if there is some proposal to make testing
a better/closer 'rolling' release that ppl like me can enjoy better:)

cheers,

P

<div dir="ltr">Hi,<div><br></div><div>I am enjoying Debian&#39;s testing branch as a reasonably stable and up-to-date &#39;rolling&#39; release, and I have to say it satisfies all my desires, almost. The one thing that bothers me is that every two
years, the unstable/testing branches are frozen to certain extent because of the stable releases. This means the testing branch can be quite lagged behind upstream releases. One example is gcc, with gcc-11 released almost 6 months ago, and it is still
not default in debian testing - I know it is being worked on right now and probably only a couple days away, but still...</div><div><br></div><div>So the question is, why not cut a release branch every two years, and at the same time keep the unstable/
testing alive? Is it because debian developers think it&#39;s too much work to reconcile the differences later, so they prefer freezing?</div><div><br></div><div>Some ppl recommend arch for this reason, but I am already familiar with apt&#39;s way of
things, and would hold off switching before I have a better understanding of the bigger picture.<br></div><div><br></div><div>I am certainly not qualified to make recommendations here, just wondering what is the reason behind it and if there is some
proposal to make testing a better/closer &#39;rolling&#39; release that ppl like me can enjoy better:)</div><div><br></div><div>cheers,</div><div><br></div><div>P</div><div><br></div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.user

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

<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><a href="https://wiki.debian.org/ReleaseProposals" rel="noreferrer" target="_blank">https://
wiki.debian.org/ReleaseProposals</a><br></blockquote><div><br></div><div>Great list, contains a lot of what I have to say.</div><div><br></div><div>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&#39;t abandon us:)<br></div><div><br></div><div>If testing is part of QA, then popularizing it
should benefit. Staying closer to upstream releases gets my vote. Quote from the page, &quot;Looks like it&#39;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.&quot;</div><div><br></div><div>cheers,</div><div>P</div></div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmFvrn0tFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh CmsP/iGbL+cjTiEzbQFKG0fTFoCvHBQES9+kZJ3+YmIWDy3JNwzaIQLd/oNiaHeM 5y4umBj9049byhSQ2TSMX7oDclfzwGAeEwUB43/fkq9WmFcYpQfkY22Yw9korgFX yPhk8TE/x7VA69DdbMUTCMO0r58ZH/k6sGkfjG96SnaJIDY6eqCkci3XBe1kURKj +JUXRlY8iqCb4DUK3JBWYlOifUtAWDExx21G1hGDPRHF9HIR2Fz9ti8Q/l1ihOeC jC884EcYjf6/3DqGAcYxtuYIZrPIDPW1WW3ZS0EyIJYoz2w2EXZOxZ5PqNzF4DKy rp9A3wOJW+CizmAo6rUcuc17fMnK0CjKeo+C92W0YZzxNUwvUoPyToJe7AocbZMq VqG52fn6jEszR5V1rCyVxd721YOULCdr0dqAySLtBzdnA/mLuAkIeJgjpeVCVPOQ nhZFLqgyim9HZgQsuk8BhexUgNei1vGNzaVlZ8QK6i79JPWeiP3EJRR3MGk/RtHR teLCMSL/+roT6GjkKrUMXWj6Md5xXTtjVsxTwC8ojfwJEl143x6O8bf+b3dlpL2f JdwuODrrxbwdwmfoEXOCttxRgPJvsL6gbk4h2SyPCkMPUpqNnXykZY9RhF7WFKXn Gp6LnF2nQrTmG+bRHu+uJviTEU3HiBo9cyXdIgM01S7Xkofe
=8W7B
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

-----BEGIN PGP SIGNATURE-----

iQKTBAABCgB9FiEEl65Jb8At7J/DU7LnSPmWEUNJWCkFAmFwmDlfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 QUU0OTZGQzAyREVDOUZDMzUzQjJFNzQ4Rjk5NjExNDM0OTU4MjkACgkQSPmWEUNJ WCktFhAA2Aa0ZU1atxKIuayqhXHEHrQKwvj8GCHTZ/fQYmyOS+AUatwzvf23+7CU 5z3POCkBi6lrpFSsfHEHeI49rkJSdaAj5AjZNhvNlKdYaByHx+CxvAz42GawBb2Z r2m8UBxyWTLs3K8o8SR36HMAcjjJD7rS/y+efLuMlNwp2+6F+8L/6kvxNW0yR5MH 56LIj6vU9+w8mVzCNE6c9tY/xMk07VFcBRwoOX7BrseRNa2GyoBMk75JUSOuw8fZ eEOzMZA9yt3tDSPVszty328Ya/fFShCqrUnicdWtTaI4RrF3gwESMLH4TBLkMAGs buP4JM1ubvdYjgAX5HstLMVeRlyWDa9AkT3f7dWogAx+OdAQbLz1eCnhT16pz9m9 5aPhVj702cschYqlB2jKQhPQYTQELe105WRRTUnRP0NWqvx6UkdkPKuUMx5RNrVF kfTsx9hSLKyenG1/z7wHLmyAQkmiulYuIHSa1+yoAFzxvY/XYWmL062Fs0l18rOF vuEXPjk4NKR/UpeJDrJzxQpoCfhOf5ZUrgxdnwYELpNqs3gypmZWTy+XnHGgUafr yYDbL9Jb8YwGwn5H3XLP26HhbHmf0JnaBM3rQ5Yt3jonnYW8Us7gxuX6wYTeqnT1 iblBG383k3kZ0Sz2oyWfbniLnz/7SYtcjWQApai58zi/KKUY7S4=
=njDc
-----END PGP SIGNATURE-----

--- SoupGate-Win32

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

-----BEGIN PGP SIGNATURE-----

iQKTBAABCgB9FiEEl65Jb8At7J/DU7LnSPmWEUNJWCkFAmFwthNfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 QUU0OTZGQzAyREVDOUZDMzUzQjJFNzQ4Rjk5NjExNDM0OTU4MjkACgkQSPmWEUNJ WClGGw/9HBYdabYqBeEt7AqPoC6HRq0V6QkamiATwtK+3CrEk9kBspCeVsGeoFyn yy/M/hcS9oys0N7ij8oqIb0qteR1J8v6BBx+aODKGkqY6oAINxZnuQrzKxO/0jHm Z5jdTp11Th+py5SBtmc73zhFedRObLMbrx+8OcZPxbYhiwUa4c5NLSuyfhoYRY5f dYGZ3r+TXNuZ7YN1vvSQSLB11VmWVBTxB7yDvIPBPdAqEIBtp4uAQqQrHnEOT2yD eVmvGVcpP59mBXG8XuV98iQ/rNsODJbYT+NeVs2yqEMdSLyhYXinTwiZb5Vcdnqn Iy0bDBw4hFz3Ew45AkIGhPAaNEfV3q1VxgxKOd0P6M79fbI2YVbAQQ2sSaud3dfg SCHG+Ea0QQgNW1EXmjR2+tY7XFKqtYS+unNa6RRnFe0/L9uoCPnFSgbGAehLMZ4k MsoxOo0rgumpnn+qcEpPJyus4JsfOyP9XOCAwbmKoJYTLO4t3lKNVWiPoLgTFhV6 RNizd8S4kOCWqpmKvzFSdr07NDKkbaw1/gk9RGoOougSwoz26lsdiaQlfVjRyVk7 /uGcCYkGeIAV4UZ1XUJapQDse8zBx/DBLzDRLqV4x8tdXivByMIBPI3oBJINRg6g TY2zt7TAxqGGNHDb/4E+OiM82U5dvpctH3tKD90ZVGLCukhRHDg=
=QeDC
-----END PGP SIGNATURE-----

--- SoupGate-Win32

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE5E64jOIbhY42OXqk/8eFRO8iNBwFAmFykasACgkQ/8eFRO8i NBw7WA/+LMt1jCgmUILda6KmA5f5teWk/GVI5ykQlnXjZ1QMvObpPII/I240aUC2 Pvvq+DjBE5LoNfiid9pCF7rlqIglg3E1A7y8avT+r5nQTTkjZBY/vlJxosPmKg9B 2LA2onGxG+YgQWUWjVnqpYJlo85OMiiDIhnHd3titZTm2gJpYo0VonARjIYgiATq mAw8Vm3Rk3GTREfaMUJzLkw7/VDnlDX8i1mjIF6fV49fpZiR5g0iNU+n8s5/Ns/f JuLmj9fXyE1JnG7txtqk2n0dOIEFOrs+tAY4ZhzZaMYeLY1WXK93b7pawwe5fx8C LTay3cfVMNwpdClJKMAoWG2sBeXSQnoCtj+d0I6u56h/DwFIQ/SmsrQoAzDY2Sll TUl+hil2hR8UnTQ9jL7kL1MblblstNA6bpEpJ3B66n5yLjlLFW7ySbh+AqK2ryew BwaL0q5Fdn+9Jr0MrgZ5AjZNqLMW+xRJTVbzBmovYm0chbPLvu8nQdDzYjt8U+JA M8vwB5Nu419HXBu+64s17T8MwBlt0io9gbrH6Agl1kwXUfISOiasBzZmostlSFiG c4v6UueBnlXhGvNZ3JeUpEHvOrILnxndsXiP+KBkq9j7JNwy7/CDYpcLleW6Zcqy ycWSn64lh1vx8mQZ/O5bgpF6lnSu+0VvyJ+2iRDmzYp3eEjCeaA=
=7w77
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)