From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1MpKRt-0000mk-I9 for garchives@archives.gentoo.org; Sun, 20 Sep 2009 11:19:21 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id F04BFE07A9; Sun, 20 Sep 2009 11:19:19 +0000 (UTC) Received: from vms173011pub.verizon.net (vms173011pub.verizon.net [206.46.173.11]) by pigeon.gentoo.org (Postfix) with ESMTP id DC4F1E07A9 for ; Sun, 20 Sep 2009 11:19:19 +0000 (UTC) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-15; format=flowed Received: from gw.thefreemanclan.net ([96.245.54.239]) by vms173011.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KQ900C74OROWV30@vms173011.mailsrvcs.net> for gentoo-dev@lists.gentoo.org; Sun, 20 Sep 2009 06:19:00 -0500 (CDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by gw.thefreemanclan.net (Postfix) with ESMTP id E509D15E4ED8 for ; Sun, 20 Sep 2009 07:18:59 -0400 (EDT) Message-id: <4AB60FA3.90903@gentoo.org> Date: Sun, 20 Sep 2009 07:18:59 -0400 From: Richard Freeman User-Agent: Thunderbird 2.0.0.23 (X11/20090912) To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Stabilization of Python 3.1 References: <200909191848.33225.Arfrever@gentoo.org> <20090919190657.31f109a3@mail.netloc.info> <4AB51317.1000108@gmail.com> <1253381283.31816.9.camel@TesterBox.tester.ca> In-reply-to: <1253381283.31816.9.camel@TesterBox.tester.ca> Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 715cdc94-897c-4b85-b194-63e01b83dd62 X-Archives-Hash: 111f19b51c37a08cd74c73e8a842c5ae Olivier Cr=EAte wrote: >=20 > ~arch is for testing ebuilds, not the upstream package >=20 I'm pretty sure this isn't the case - at least not as cleanly as you=20 suggest. Certainly testing the ebuilds themselves is part of the reason=20 for having ~arch, but upstream readiness is part of it as well. If a=20 package hit ~arch and we got 10 serious bugs that were all upstream=20 problems and then somebody filed a STABLEREQ I know that I wouldn't be=20 the one to stabilize it. The whole point of having QA is so that people who don't want to be=20 bothered with bleeding-edge packages aren't bothered with them. Masking=20 is for packages with known serious problems, ~arch is for packages that=20 we think are fine but don't have much production history with, and=20 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=20 for going stable. Others have made some of these suggestions, but let=20 me consolidate some ideas that have come up: 1. A tracking bug should be created to track 3.1 stabilization issues=20 (assuming it doesn't already exist). 2. Portage (and other system packages) deps should be checked to ensure=20 it pulls in the current version. This should be carefully coordinated. 3. -dev-announce message sent out to check your python deps and fix=20 them (logging blockers as needed). This need not be carefully coordinate= d. 4. einfo message about not eselecting the new version of python. News=20 message as well. As long as the current version doesn't go anywhere and the current=20 version can be re-selected at-will, then I don't see how users can get=20 themselves into a corner. The ability to support stuff like this is the reason we have SLOTs in=20 the first place.