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 :-) :-)
