Richard Freeman wrote:
> 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.
>
>

Thanks for explaining that better than I could. 

Dale

:-)  :-)