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.
- Testing should contain no RC bugs and hence be releasable at any given point (after toolcahin/library ladings in the beginning of the cycle).
- No accidental migrations from unstable to testing since the pkg-maintainer needs to request and a release manager needs to agree.
- High quality stable releases.
- Development could be planned since release date is fixed.
- We wouldn't need to completely drop packages if the maintainer is lazy.
- Possibly a lot of work for the release managers since they would need to approve each package before it could enter testing.
- Package maintainers would risk public humiliation when their package breaks testing.
- Risk of having pkg-maintainers push their packages in the last minute, failing, and being "shit out of luck" and stuck for an old version for a year (not sure if this is a bad thing).
- Rolling stuff back ie downgrading is something we aren't all that familiar with.
- Stable might have older packages if maintainers aren't active.