Olivier Crête wrote:
~arch is for testing ebuilds, not the upstream package
I'm pretty sure this isn't the case - at least not as cleanly as you suggest. Certainly testing the ebuilds themselves is part of the reason for having ~arch, but upstream readiness is part of it as well. If a package hit ~arch and we got 10 serious bugs that were all upstream problems and then somebody filed a STABLEREQ I know that I wouldn't be the one to stabilize it.
The whole point of having QA is so that people who don't want to be bothered with bleeding-edge packages aren't bothered with them. Masking is for packages with known serious problems, ~arch is for packages that we think are fine but don't have much production history with, and stable is for packages that are known to be decent with history.
However, I'm not convinced that the 3.1 issues need to be a showstopper for going stable. Others have made some of these suggestions, but let me consolidate some ideas that have come up:
1. A tracking bug should be created to track 3.1 stabilization issues (assuming it doesn't already exist). 2. Portage (and other system packages) deps should be checked to ensure it pulls in the current version. This should be carefully coordinated. 3. -dev-announce message sent out to check your python deps and fix them (logging blockers as needed). This need not be carefully coordinated. 4. einfo message about not eselecting the new version of python. News message as well.
As long as the current version doesn't go anywhere and the current version can be re-selected at-will, then I don't see how users can get themselves into a corner.
The ability to support stuff like this is the reason we have SLOTs in the first place.
