This is based on HighQualityStableWithFixedReleaseDate, combined with division to separate trees by architecture.

Consider the "distribution" as couple of authonome distributions, each for one architecture. Thus, there would be in fact "unstable/i386", "unstable/hppa", "testing/i386", "testing/s390" etc.

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.

Developer gets new version into the tree separately for each architecture, although technically he could get it by one query (by selecting several architectures, or even all). This allows him to separate the functional and non-functional packages by architecture. E.Q.: If package is functional on all excepting -whatever- architecture, he would simply get the package into all architectures expecting -whatever-. The -whatever- architecture package could get in later, after the architecture-based problem is fixed.

If a developer would fail to get a new version of a package in to shape, we would simply release the old version for the affected architecture(s).

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:

Other words, if the package is important, somebody finally will fix it. If it isn't, and/or architecture is niche and nobody cares, than why should everyone suffer because of that?

If the package is likely to be highly security-exposed, the maintainer has always the freedom to choose to stay with the older (functional) version for all architectures, especially if this is obviously less evil than few simultaneous versions.