Unstable would be seen as a pool of semi stable packages, not as a distribution.

Testing would start as a branch of the previous stable, immediately after stable has been released. Packages and subsystems would "land" on testing when a testing maintainer agrees to the package maintainers request for landing.

If an RC bug would crop up in testing, this would mean testing would become broken and no further landings could happen until the rc bug was fixed, or the breaking change rolled back. This would be combined by dinstalls every hour, some automated testing and an assignment of who is to blame in big *bold* letters.

The release would be time based. We would freeze testing in late June, meaning no more landings. Then in August we would "copy" testing in to stable, and unfreeze testing to start landing stuff again.

If a developer would fail to get a new version of a package in to shape, we would simply release the old version.

Large toolchain or library changes likely to entirely break testing would only happen in the beginning of the new cycle. Any package that would become broken by this would cause testing to breake until the issues are fixed (since the large landing will not get rolled back).

Each cycle would start with the landing of large changes that will most likely break testing (like GCC 4.x or SELinux). Then the rest of the cycle would be fixing packages and making landings that will (hopefully) not break testing. Any large change would thus get almost a full year of testing.

We could land non-critical and clean subsystems (like KDE or Gnome) in mid testing, but if testing would go bust, the landing would quickly get rolled back.

Pros:

Cons: