My idea is to release a version at the time when the most popular architecture (yep, i386) is free from RC errors; if other architectures still contain bugs, tough luck we don't drop them out but their next stable version is delayed.
Release would therefore be performed by architecture; bugs for an obscure processor would not delay the roll-out of the most popular versions, but they would still benefit from it. The remaining bugs would be isolated per architecture.
E.g. we would release an error-free Debian 3.1 version for the i386 architecture on January 1st, PPC on January 15th (meaning all errors are solved by then), Sparc on February 8th, ... and finally ARM on April 4th. All of these dates are ficticious and depend on how long it takes to remove all RC bugs from each architecture.
As a last point, we should hold the release of Debian 3.2 for i386 until version 3.1 has been released for all other architectures.
- Bugs need to carry an architecture flag. Bugs have to be confirmed for all architectures.
- We already have different versions for different arches. Take libglib2, wich has a version for i386 and another for the others.
- Different arches within a release would contain different versions of the same packages.
"Would propagation to testing require that a package build on all architectures, the way it does now? If so, then see JoeyHess's comment in TooManyArchitectures, because this won't solve the problem." -- KenBloom