List Archive: gentoo-dev
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
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
> 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
> 3. -dev-announce message sent out to check your python deps and fix
> them (logging blockers as needed). This need not be carefully
> 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.