It's time to discard the old boolean model where a version of Debian was either unreleased, and thus constantly changing and potentially unfit for use at any given time, or released, and thus on the long slide to obselescense. So far, we've been working around and increasingly invalidating this model in bits and peices:

• d-i release candidates, at first only being a working cut of the installer for the next Debian release, have grown to become basically snapshots of the whole distro, and nearly releases in their own right.
• The testing security team, which ensures that we either fix or at least track security issues in testing, thus lessening the security related reasons to not use testing.
• Backports and volatile, which provide new software for released versions of Debian.
• Unofficial installers for stable with updated kernels etc.

All of these erode the idea that the goal of Debian is to produce a succession of static releases. Both in Debian and in the world at large, the lines are increasingly blurring between released and not, between static software and software under development. But this makes deciding how/if to use Debian more complex for the many users for whom the last stable release won't cut it. These users have to decide between sticking with stable and piling various updates on it while hoping nothing breaks it, or using testing and hoping that it's well enough supported by the project to do the job. Often none of these choices are ideal, and often we don't present things to users in ways that help them make a good choice.

I propose that we form a team to ensure a Constantly Usable Testing (CUT), which would coordinate efforts to make sure that these things -- most of which are already being done on a best-effort basis -- always happen, and can be counted on by our users:

• Testing should be installable at all times.

• = serious bugs should be fixed in a timely fashion, or buggy software dropped from testing.

• Security issues in testing should be either fixed ASAP or tracked so that users can deal with them.
• Upgrades from older versions of testing should always work.
• Snapshots should be made available regularly, so that users who need a firm foundation for deployment have one. They'd be numbered, so we could call them cut 4, cut 5, etc. Each would be a snapshot of testing at a point when it was in especially good shape.

Supplanting the stable release is explicitly not a goal, although it's hard to predict what the effects of CUT would be in the long run on the stable release process. Stable is exactly what some of our users need, but CUT would provide another well defined option to our users.

The CUT team would probably be similar to the release team in many ways. There are obviously a lot of details to work out, and I don't expect that it will be easy, but to me, this is a much more exciting thing to work on than yet another stable release.