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