| 13 |
to remove the requirement that the testing suite must freeze during |
to remove the requirement that the testing suite must freeze during |
| 14 |
the release process. |
the release process. |
| 15 |
|
|
| 16 |
|
<a name="introduction"> |
| 17 |
# Introduction / Problem scope |
# Introduction / Problem scope |
| 18 |
|
|
| 19 |
Currently, as the project nears a new stable release, a freeze is instituted |
Currently, as the project nears a new stable release, a freeze is instituted |
| 60 |
to the next release, as release goals will likely be set relative to |
to the next release, as release goals will likely be set relative to |
| 61 |
the starting point. |
the starting point. |
| 62 |
|
|
| 63 |
|
# Past and present release methods |
| 64 |
|
|
| 65 |
|
## Frozen (< 2000) |
| 66 |
|
|
| 67 |
|
Before the introduction of testing, Debian used a simple release process |
| 68 |
|
where the unstable suite was snapshotted into a `frozen` suite. This suite |
| 69 |
|
would then be used exclusively for preparing the next stable release, with |
| 70 |
|
unstable continuing in parallel. |
| 71 |
|
|
| 72 |
|
Before freeze Freeze Release |
| 73 |
|
|
| 74 |
|
[unstable/sid]-------------------------------------------------------------- |
| 75 |
|
\ |
| 76 |
|
[frozen].-.-.-.-.[stable/R_N].-.-.-.-.-.-.-.-.-.-.-.-.-. |
| 77 |
|
|
| 78 |
|
[stable/R_N-1].-.-.-.-.-.-.-.-.-.-.-.[oldstable/R_N-1].-.-.-(EOL) |
| 79 |
|
|
| 80 |
|
--------: Normal activity. Standard rules for uploads and migrations. |
| 81 |
|
.-.-.-.-: Release targeted activity. Freezes and limited uploads. |
| 82 |
|
\ \ \ \ : Package migration activity. |
| 83 |
|
|
| 84 |
|
|
| 85 |
|
### Benefits with the `frozen` method |
| 86 |
|
|
| 87 |
|
* Work in unstable continued, unaffected by the freeze. |
| 88 |
|
|
| 89 |
|
### Problems with the `frozen` method |
| 90 |
|
|
| 91 |
|
* Release work started from a buggy suite. |
| 92 |
|
* Duplicated effort in unstable/frozen. |
| 93 |
|
* RM had more work/responsibilities, and was prone to burn-out. |
| 94 |
|
|
| 95 |
|
## Testing (2000-Present) |
| 96 |
|
|
| 97 |
|
The testing suite was introduced in Debian between the release of potato |
| 98 |
|
and woody, in the fall of 2000[[1]]. The goal was to provide |
| 99 |
|
a suite that was in a better state for release preparation, by having |
| 100 |
|
both automated and manual tools to keep down the level of bugs and |
| 101 |
|
general volatility. |
| 102 |
|
|
| 103 |
|
As a pleasant and convenient side-effect, the new suite also provided |
| 104 |
|
a "slightly less buggy unstable" for developers and end-users, who wanted |
| 105 |
|
newer software/features not available in stable, but wanted some level |
| 106 |
|
of protection to the relatively unpredictable nature of unstable. |
| 107 |
|
|
| 108 |
|
Before release Freeze Release |
| 109 |
|
|
| 110 |
|
[unstable/sid]----------.--.--.--.-.-.-.-.-.-.------------------------------ |
| 111 |
|
\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ |
| 112 |
|
[testing/R_N]----------.-.-.-.-.-.-.-.-.-.-.-.[testing/R_N+1]--------------- |
| 113 |
|
/ / \ |
| 114 |
|
/ / [stable/R_N].-.-.-.-.-.-.-.-.-.-.- |
| 115 |
|
/ / / / / |
| 116 |
|
[R_N p-u].-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- |
| 117 |
|
|
| 118 |
|
[stable/R_N-1].-.-.-.-.-.-.-.-.-.-.-.-.-.-[oldstable/R_N-1].-.-.-(EOL) |
| 119 |
|
|
| 120 |
|
--------: Normal activity. Standard rules for uploads and migrations. |
| 121 |
|
.-.-.-.-: Release targeted activity. Freezes and limited uploads. |
| 122 |
|
\ \ \ \ : Package migration activity. Spacing of marks is a rough |
| 123 |
|
indication of frequency. |
| 124 |
|
|
| 125 |
|
During the freeze, the testing suite becomes entirely dedicated to the |
| 126 |
|
release work. In practice, this also means that unstable is also to |
| 127 |
|
some extent frozen from non-release activity for many packages, since |
| 128 |
|
it still serves as the main route to testing for new uploads. |
| 129 |
|
|
| 130 |
|
### Benefits with the testing method |
| 131 |
|
|
| 132 |
|
* Release branch has far fewer bugs at the start of the release process. |
| 133 |
|
* (Ideally) shorter release process with fewer problems. |
| 134 |
|
* Large user-base for testing stable-targeted fixes. |
| 135 |
|
|
| 136 |
|
### Problems with the testing method |
| 137 |
|
|
| 138 |
|
(See [Introduction](#introduction)) |
| 139 |
|
|
| 140 |
|
[1]: http://lists.debian.org/debian-devel/2000/08/msg00906.html |