This is a variant of "let some other distro be our stable". The other distro is Debian.

Divide the project along stability lines (stable, testing, unstable, experimental), but pass the entire distribution from step to step. When the testing crew is done with its current release, it pulls a new collection of packages from unstable and stabilizes it. When the stable crew feels that a particular Testing 'release' is good enough to be a real release, they adopt it, put final polish on it, and formally release it.

The difference between this and the current scheme is that unstable is upstream for testing, and testing is upstream for stable. The developer who initially packages software doesn't necessarily babysit it all the way to release unless they happen to be on all the teams and want to maintain the package the whole time.

Advantages

Disadvantages

Other thoughts

Installer is simply an 'unstable stage' package set. Once it 'works' enough for the Testing team to focus on debug, they 'freeze' that version by adopting it into their current/next release. There's no need to hold up any stage because of the installer.

Another way to look at this is that the "unstable" team adopts experimental packages and makes them stable enough to co-exist with testing packages. The "testing" team adopts unstable packages and makes a coherent, release-quality set of packages out of them. The Stable team adopts an entire set of "tested" packages, gives them a little more QA, and then does security support on them. The three stages are layers between the four levels of stability. "Experimental" package developers are indistinguishable from traditional upstream development.

?RobertDeForest