[[!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.

[[!toc ]]

<a name="introduction">
# 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.

# Past and present release methods

## Frozen (< 2000)

Before the introduction of testing, Debian used a simple release process
where the unstable suite was snapshotted into a `frozen` suite.  This suite
would then be used exclusively for preparing the next stable release, with
unstable continuing in parallel.

    Before freeze       Freeze           Release

    [unstable/sid]--------------------------------------------------------------
                        \
                        [frozen].-.-.-.-.[stable/R_N].-.-.-.-.-.-.-.-.-.-.-.-.-.
     
    [stable/R_N-1].-.-.-.-.-.-.-.-.-.-.-.[oldstable/R_N-1].-.-.-(EOL)

	--------: Normal activity.  Standard rules for uploads and migrations.
	.-.-.-.-: Release targeted activity.  Freezes and limited uploads. 
	\ \ \ \ : Package migration activity.

### Use cases with `frozen`

Users were divided into two sets, those using `unstable` and those using
`stable`.  Very few users would use both, as the two lines of development
would quickly diverge from each other.

### Benefits with `frozen`

 * Work in unstable continued, unaffected by the freeze.

### Problems with `frozen`

 * Release work started from a buggy suite.
 * Duplicated effort in unstable/frozen.
 * RM had more work/responsibilities, and was prone to burn-out.

## Testing (2000-Present)

The testing suite was introduced in Debian between the release of potato
and woody, in the fall of 2000[[1]].  The goal was to provide
a suite that was in a better state for release preparation, by having
both automated and manual tools to keep down the level of bugs and
general volatility.

As a pleasant and convenient side-effect, the new suite also provided
a "slightly less buggy unstable" for developers and end-users, who wanted
newer software/features not available in stable, but wanted some level
of protection to the relatively unpredictable nature of unstable.

    Before release         Freeze             Release

    [unstable/sid]----------.--.--.--.-.-.-.-.-.-.------------------------------
         \ \ \ \ \ \ \ \ \  \   \    \       \     \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    [testing/R_N]----------.-.-.-.-.-.-.-.-.-.-.-.[testing/R_N+1]---------------
                                         / / \
                                        / /   [stable/R_N].-.-.-.-.-.-.-.-.-.-.-
                                       / /          /          /           /
                                   [R_N p-u].-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-

    [stable/R_N-1].-.-.-.-.-.-.-.-.-.-.-.-.-.-[oldstable/R_N-1].-.-.-(EOL)

	--------: Normal activity.  Standard rules for uploads and migrations.
	.-.-.-.-: Release targeted activity.  Freezes and limited uploads. 
	\ \ \ \ : Package migration activity.  Spacing of marks is a rough
	          indication of frequency.

During the freeze, the testing suite becomes entirely dedicated to the
release work.  In practice, this also means that unstable is also to
some extent frozen from non-release activity for many packages, since
it still serves as the main route to testing for new uploads.

### Use cases with `testing`

The introduction of the new suite also introduced a type of continuum
in which users now have more flexibility in selecting what to have installed.

 * `unstable`: only the "bleeding edge" of Debian updates.
 * `testing`: only the "leading edge" of Debian updates.
 * `testing/unstable`: A hybrid solution of the two previous use cases,
    allowing for a reasonable balance between them.
 * `stable`: The latest stable release.
 * `stable/testing`: the stable release with perhaps some newer packages
    installed, typically also making use of "APT pins" to prevent unwanted
    upgrades.  Less common now with the inclusion of backports and volatile
	as official Debian services.

### Benefits with `testing`

 * Release branch has far fewer bugs at the start of the release process.
 * (Ideally) shorter release process with fewer problems.
 * Large user-base for testing stable-targeted fixes.

### Problems with `testing`

(See [Introduction](#introduction))

[1]: http://lists.debian.org/debian-devel/2000/08/msg00906.html