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

arrows indicate a dependency link (non-arrow side is the depending package)

multiple arrows that arrive at the same level indicate that the dependency can be met by any of those packages

last digit increment in a package name indicates a fork from a previously stabilized package

circular dependencies are not considered, but hopefully, a smart developer should be able to figure out how to support such a scenario

a higher level package must inherit the same versions of dependencies of those packages that it depends on (in the example map, if gnome2.8.1-1 depends on gtk2.4-2, then it is automatically dependent on gtk2.4-2, gcc3.3-2, and debian-base3.2-3; or it could be dependent on gtk2.4-2, gcc3.3-1, and debian-base-3.2-2; or gtk2.4-2, gcc3.3-1, and debian-base3.2-1; but gtk2.4-2, gcc3.3-2, and debian-base3.2-2 would not be permissible). These varying package dependency configurations will be discussed subsequently.

it would be useful to have a package that could generate the software map (for the developers' sanity) for all software or subsets in the pool

note that the example package pool map is not based entirely on the current reality of available Debian packages

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.

Cons:

potential abuse via the ability to kill any package by reporting an RCB at the last minute before the ?RC0/?RC1 transition.

potential abuse via the ability to kill any package by reporting an RCB during any point in ?RC2 (perhaps 2 out of 3 reviewing developers including only one of the package maintainers must approve ?RCBs at this stage).

debian3.2R0 would probably take 12-18 months to be released because package management modifications (dpkg, apt-get, moving everything to a single pool, etc) could take 3-9 months.

?RCBs may potentially be reported in packages that were previously declared as stable (fall back to previous previous stable???)

Pros:

all package versions can coexist peacefully in a universal pool (gnome2.10.0 can exist along with gnome2.9.5, gnome2.8.1, gnome2.8.0, gnome2.6.1, etc.). there is no longer any need for testing/unstable/experimental/volatile/supermegafryurdisk/etc to compensate for new package development.

when debian3.?2RC1 is initialized at month 6 day 1, debian3.?3RC0 can be initiated right away from previous stable (probably like debian3.1R2 at this point). in other words, there can be two potential releases in the works at any given time; producing stable releases approximately every 6 months.

packages lag only between 4-10 months (usually on the 5 month side depending on how well ?RC0 integration goes)

users can install any package in the universal pool (I suggest big warning flags for those packages with ?RCBs or security issues). say gnome2.8.1-1 is in the stable release, but the user wants to run gnome2.11.3-1, so they do "apt-get install gnome2.11.3-1" and they get a warning about installing from outside the stable realm, then they see ?RCBs, security issues, and other potential warnings about using non-stable packages.

no need for backports.org. newer packages built to depend on the stable system can be built directly into the universal package pool.