[[!meta title="DEP-10: parallelized ('rolling') release management"]]

    Title: parallelized ('rolling') release management"
    DEP: 10
    State: DRAFT
    Date: 2011-04-30
    Drivers: Sean Finney <seanius@debian.org>,
	 Raphaël Hertzog <hertzog@debian.org>
    URL: http://dep.debian.net/deps/dep10
    License: GPL
    Abstract:
     Proposal for changes to release management methodology and infrastructure
	 to remove the requirement that the testing suite must freeze during
	 the release process.

# Introduction / Problem scope

Currently, as the project nears a new stable release, a freeze is instituted
on the testing suite.  The freeze is put in place to allow the release team
to focus on resolving the remaining Release Critical (RC) bugs for the next
stable release, and at the same time to prevent regressions from new uploads.
Typically the freeze begins as an advisory "soft freeze", which over
time increases in strictness and levels of enforcement.

Unsuprisingly, as the strictness of the freeze increases, there is an
inversely proportional decrease in other non-release targeted maintainer
activity.  Since unstable still is the preferred route for packages to
reach the new release during this period, maintainers are highly discouraged
and in some cases prevented from doing non-release targeted activities
in unstable.

The reduction of such non-release activity is viewed as problematic in
this DEP, for some inter-related reasons:

 * New features and innovations are put on hold, or at least not commonly
   available, until after the release is made.
 * Overall Maintainer activity decreases as freezes persist.
 * Potential userbase is lost (missing feature X, switch distro).
 * The volatility of testing/unstable increases (and thus quality decreases)
   with a deluge of new uploads after the freeze is lifted.

As Debian is well known for taking a "release when it's ready" approach, the
freeze periods are generally known to last considerable amounts of time.
Consider the last three freezes:

 * squeeze: 4 months
 * lenny: 7 months
 * squeeze: 6 months

This means, in rough terms, that the when testing thaws, that the Debian
project may be starting from a state half a year behind comparable
distributions.  

While the resulting stable releases are well known for their high level
of quality and stability, it is at a considerable cost.  The project is,
in essence, starting from a 6 month standstill, will be similarly
out of date with comparable distributions.  Furthermore, both the standstill
as well as the subsequent rush of uploads will introduce further delays
to the next release, as release goals will likely be set relative to
the starting point.