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.

• Experimental group
  • Indistinguishable from real upstream developers
• Unstable group
  • Fixes upstream bugs
  • performs 'normal' debian packaging role
• Testing group
  • Integrates a chosen set of packages(versions) into a coherent 'release'
• Stable group
  • Ratifies stable release
  • Security updates

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

• People can focus on the part of development which interests them (features, integration, security fixes, ...).
• Snags at any stage don't necessarily slow the other stages down.
• Different development styles can be applied at different stages. The stable team would probably not 'own' packages at all, kinda like the BSD core teams.
• Development of a particular package could still be targeted for a particular sub-release.
• Each down-stream stage gets to decide when each upstream package is ready for release. It's not necessary for a particular stage to focus on the goals of its successor. Experimental developers don't have to worry about anything except their own packages (already the case). Unstable developers don't worry so much about version waves. Testing developers would focus on the set of packages they selected from Unstable to become the next testing. There would be no de-stabilizing caused by upstream changes because it's up to downstream to roll them in. Each stage could pick and choose the upstream package version which best fits into its stage.

Disadvantages

• Stable might be permenently 1-2 years out of date instead of being new once every four years. Could also be an advantage.
• It might be hard to find people who actually WANT to work on the stable/testing teams.

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