The following may be the most extensive suggested release process modification yet. OK, with that said, the first step is to abandon the current concept of stable/testing/unstable distributions, and merge all packages that encompass the above distributions into a single pool. This may sound crazy at first, but the ideas that follow, I believe, simplify the package management and release process drastically.

Now, with all packages located within a single pool, a slight rearrangement of dependencies will be required. Packages that implement basically the same feature set are considered to belong to a new concept called a "level." A sample graphical package map in the new regime follows A few notes on the above figure

Note that the above would require some subtle changes to the package management system. One of which is that dependencies are satisfiable by multiple packages (for example dependencies of gcc3.3-1 can be satisfied by either debian-base3.2-2 or debian-base3.2-1).

Now, on to my idea for a refined release process (utilizing the above refinements to the packaging system of course). I'm going to use the acronym RC for Release Candidate and RCB for Release Critical Bug (most documents seem to call both RC). I'm also going to call the next release debian3.2 for lack of a better name. The first release candidate, debian3.?2RC0, will begin at month 0 in the time line. This RC can be thought of as roughly equivilant to the current unstable distribution. On day 0, all of the packages from the previous stable release (debian3.1R0) are forked (the last digit of the name of all packages is incremented), and all relevant strings are changed to reflect the name and version of the new release.

From now until month 6 day 0, the package system will try it's best to include the packages with the highest version number that do not contain any ?RCBs. As soon as an RCB is reported, the offending package (along with all dependent packages that can't fall back on other packages on the same level as the offending package) is instantly rolled back to the previous stable version. When the RCB is fixed, the offending packages are brought back into the distribution. The system always favors the package with the highest version number so long as that package contains 0 ?RCBs. For example, on month 3 day 4, debian3.?2RC0 consists of the packages contained within the dashed line in the following figure On month 3 day 5, a user reports that there is an RCB in gtk2.4-2. The system sees that it can fall back on the last stable gtk package (gtk2.4-1), but will also need to revert to gnome2.6.1-1 and evolution1.4-1 as in the following figure because gnome2.8.1-1 was not built to depend on gtk2.4-1.

The above process produces a distribution with 0 ?RCBs at any instance in time. Thus, at month 6 day 1, a virtually bug-free distribution is available, which will now be called debian3.?2RC1 (equivilant to current testing). The key differentiator is that packages in this RC with ?RCBs are not rolled back right away and no new packages are accepted. The package maintainers now have a 3 month window until month 9 day 0 to fix any new ?RCBs that arise. On month 9, day 0, all packages containing ?RCBs are reverted back to the versions from the last stable release. Again, the system is RCB-free. Now, from month 9 day 1 until release, the final port and polish is put on debian3.?2RC2 (a new concept, called "polish"). Any valid ?RCBs at this point, again force the offending package to be reverted back to the previous stable release, but contrary to ?RC0, the package may not return. I'd imagine the polish process should take anywhere between 1 to 2 months, at which point, debian3.?2RC2 becomes debian3.2R0. Security updates to previous stable packages (that remain within ?RC0/?RC1/?RC2) may be accepted at any point in the development process. Packages should be evaluated in terms of how well they work in the new system throughout ?RC0 and ?RC1, and packages that just don't fit or don't play well can be excluded any time during that process.