web/deps/dep10.mdwn

[[!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
1	seanius	175	[[!meta title="DEP-10: parallelized ('rolling') release management"]]
2
3			Title: parallelized ('rolling') release management"
4			DEP: 10
5			State: DRAFT
6			Date: 2011-04-30
7			Drivers: Sean Finney <seanius@debian.org>,
8			Raphaël Hertzog <hertzog@debian.org>
9			URL: http://dep.debian.net/deps/dep10
10			License: GPL
11			Abstract:
12			Proposal for changes to release management methodology and infrastructure
13			to remove the requirement that the testing suite must freeze during
14			the release process.
15
16	seanius	181	[[!toc ]]
17
18	seanius	178	<a name="introduction">
19	seanius	176	# Introduction / Problem scope
20
21			Currently, as the project nears a new stable release, a freeze is instituted
22			on the testing suite. The freeze is put in place to allow the release team
23			to focus on resolving the remaining Release Critical (RC) bugs for the next
24			stable release, and at the same time to prevent regressions from new uploads.
25			Typically the freeze begins as an advisory "soft freeze", which over
26			time increases in strictness and levels of enforcement.
27
28			Unsuprisingly, as the strictness of the freeze increases, there is an
29			inversely proportional decrease in other non-release targeted maintainer
30			activity. Since unstable still is the preferred route for packages to
31			reach the new release during this period, maintainers are highly discouraged
32			and in some cases prevented from doing non-release targeted activities
33			in unstable.
34
35			The reduction of such non-release activity is viewed as problematic in
36			this DEP, for some inter-related reasons:
37
38			* New features and innovations are put on hold, or at least not commonly
39			available, until after the release is made.
40			* Overall Maintainer activity decreases as freezes persist.
41			* Potential userbase is lost (missing feature X, switch distro).
42			* The volatility of testing/unstable increases (and thus quality decreases)
43			with a deluge of new uploads after the freeze is lifted.
44
45			As Debian is well known for taking a "release when it's ready" approach, the
46			freeze periods are generally known to last considerable amounts of time.
47			Consider the last three freezes:
48
49			* squeeze: 4 months
50			* lenny: 7 months
51			* squeeze: 6 months
52
53			This means, in rough terms, that the when testing thaws, that the Debian
54			project may be starting from a state half a year behind comparable
55			distributions.
56
57			While the resulting stable releases are well known for their high level
58			of quality and stability, it is at a considerable cost. The project is,
59			in essence, starting from a 6 month standstill, will be similarly
60			out of date with comparable distributions. Furthermore, both the standstill
61			as well as the subsequent rush of uploads will introduce further delays
62			to the next release, as release goals will likely be set relative to
63			the starting point.
64
65	seanius	178	# Past and present release methods
66
67			## Frozen (< 2000)
68
69			Before the introduction of testing, Debian used a simple release process
70			where the unstable suite was snapshotted into a `frozen` suite. This suite
71			would then be used exclusively for preparing the next stable release, with
72			unstable continuing in parallel.
73
74			Before freeze Freeze Release
75
76			[unstable/sid]--------------------------------------------------------------
77			\
78			[frozen].-.-.-.-.[stable/R_N].-.-.-.-.-.-.-.-.-.-.-.-.-.
79
80			[stable/R_N-1].-.-.-.-.-.-.-.-.-.-.-.[oldstable/R_N-1].-.-.-(EOL)
81
82			--------: Normal activity. Standard rules for uploads and migrations.
83			.-.-.-.-: Release targeted activity. Freezes and limited uploads.
84			\ \ \ \ : Package migration activity.
85
86	seanius	179	### Use cases with `frozen`
87	seanius	178
88	seanius	179	Users were divided into two sets, those using `unstable` and those using
89			`stable`. Very few users would use both, as the two lines of development
90			would quickly diverge from each other.
91	seanius	178
92	seanius	179	### Benefits with `frozen`
93
94	seanius	178	* Work in unstable continued, unaffected by the freeze.
95
96	seanius	179	### Problems with `frozen`
97	seanius	178
98			* Release work started from a buggy suite.
99			* Duplicated effort in unstable/frozen.
100			* RM had more work/responsibilities, and was prone to burn-out.
101
102			## Testing (2000-Present)
103
104			The testing suite was introduced in Debian between the release of potato
105			and woody, in the fall of 2000[[1]]. The goal was to provide
106			a suite that was in a better state for release preparation, by having
107			both automated and manual tools to keep down the level of bugs and
108			general volatility.
109
110			As a pleasant and convenient side-effect, the new suite also provided
111			a "slightly less buggy unstable" for developers and end-users, who wanted
112			newer software/features not available in stable, but wanted some level
113			of protection to the relatively unpredictable nature of unstable.
114
115			Before release Freeze Release
116
117			[unstable/sid]----------.--.--.--.-.-.-.-.-.-.------------------------------
118			\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
119			[testing/R_N]----------.-.-.-.-.-.-.-.-.-.-.-.[testing/R_N+1]---------------
120			/ / \
121			/ / [stable/R_N].-.-.-.-.-.-.-.-.-.-.-
122			/ / / / /
123			[R_N p-u].-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
124
125			[stable/R_N-1].-.-.-.-.-.-.-.-.-.-.-.-.-.-[oldstable/R_N-1].-.-.-(EOL)
126
127			--------: Normal activity. Standard rules for uploads and migrations.
128			.-.-.-.-: Release targeted activity. Freezes and limited uploads.
129			\ \ \ \ : Package migration activity. Spacing of marks is a rough
130			indication of frequency.
131
132			During the freeze, the testing suite becomes entirely dedicated to the
133			release work. In practice, this also means that unstable is also to
134			some extent frozen from non-release activity for many packages, since
135			it still serves as the main route to testing for new uploads.
136
137	seanius	179	### Use cases with `testing`
138	seanius	178
139	seanius	179	The introduction of the new suite also introduced a type of continuum
140			in which users now have more flexibility in selecting what to have installed.
141
142			* `unstable`: only the "bleeding edge" of Debian updates.
143			* `testing`: only the "leading edge" of Debian updates.
144			* `testing/unstable`: A hybrid solution of the two previous use cases,
145			allowing for a reasonable balance between them.
146			* `stable`: The latest stable release.
147			* `stable/testing`: the stable release with perhaps some newer packages
148			installed, typically also making use of "APT pins" to prevent unwanted
149			upgrades. Less common now with the inclusion of backports and volatile
150			as official Debian services.
151
152	seanius	180	### Benefits with `testing`
153	seanius	179
154	seanius	178	* Release branch has far fewer bugs at the start of the release process.
155			* (Ideally) shorter release process with fewer problems.
156			* Large user-base for testing stable-targeted fixes.
157
158	seanius	179	### Problems with `testing`
159	seanius	178
160			(See [Introduction](#introduction))
161
162			[1]: http://lists.debian.org/debian-devel/2000/08/msg00906.html