Having the current pair of repositories -- Unstable and Testing (with Experimental on the side) -- is problematic:

Let's add another step between Unstable and Testing; let's call it "Pretesting". Maintainers can submit packages directly to Pretesting. The packages progress Unstable -> Pretesting the same way as they progress Unstable -> Testing with the additional requirement:

This allows the release team simply to put a .so freeze on Pretesting to get it ready for a release.

Proposed by: MikeFedyk


The big disadvantage here is in developers' and users' brains.

Even now, we find that a lot of developers aren't taking responsibility for making sure releaseable versions of their packages are in testing (although I think that problem is less bad than it used to be, as awareness increases).

The reason why we require packages to go through unstable, in general, is that they can be tested there by users. How much testing would an additional distribution get? How much would we be dividing the already scattered attention given to validating the quality of packages in unstable by creating another distribution that needs to be tested? I would be worried about that. -- ColinWatson


This system pretty much requires a constraint on unstable that every package should have the goal of being releasable and reasonably expect that the package will be ready for migration from unstable within a certain period of time. In fact, the current system is also not working well for exactly this reason.

That means tracking the stable upstream releases in unstable unless there is good reason to do otherwise. CVS pulls and development trees belong in experemental.

Backports.org is effectively a stage between stable and testing with the requirement to compile against stable. This proposal encompass that process with automation like testing is today.

My origional thought was to have a step where the packages were compiled against what is testing today (to have a constantly buildable-against-itself release candidate), but I didn't want to mix the two after I started thinking about the idea about compilers migrating through the system and the recompilations that would require if one stage to another. But I didn't think of backports.org at the time.

What we have now:

This is the full outcome of what I am proposing. It can also be implemented partially though or even better, in steps:

Would a compiler migration from testing ===> release-candidate require all packages be recompiled in release-candidate? --MikeFedyk

See ReleaseProposals for alternatives.


As a mere user of Debian, I was shocked to learn that packages are automatically migrated from Unstable to Testing. The entire problem with releases is that Testing is too unstable for even modest production use. That these two branches are separated by a mere ten days and a few minor requirements is, structurally, a major contributor to this instability.

A new branch, if added, should go between Stable and Testing, as this is mostly where the Debian-spinoffs (Lindows, Ubuntu, Knoppix, etc) along with backports.org, end up. It seems that this is actually what you are proposing, the new branch "release-candidate". Somebody should change the title of this proposal.

I would point out that automatic migration through (now proposed) three branches instead of two does not solve the problem of stability without added requirements. Also, backports would probably always have to be migrated manually. Something like this seems like it would produce a more stable release-candidate branch:

-Ben Smith