Re: [gentoo-dev] Stabilization of Python 3.1

[Richard Freeman <rich0@gentoo.org>]

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.