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 1OTAXN-0000gL-AU for garchives@archives.gentoo.org; Mon, 28 Jun 2010 09:21:57 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5FF6AE0FB0; Mon, 28 Jun 2010 09:21:54 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 52A14E0F4F for ; Mon, 28 Jun 2010 09:21:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id F01D81B411D for ; Mon, 28 Jun 2010 09:21:42 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 required=5.5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q41EBdFTZTPH for ; Mon, 28 Jun 2010 09:21:36 +0000 (UTC) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by smtp.gentoo.org (Postfix) with ESMTP id 0D6911B404F for ; Mon, 28 Jun 2010 09:21:31 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OTAWs-0004GF-C0 for gentoo-dev@gentoo.org; Mon, 28 Jun 2010 11:21:26 +0200 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 28 Jun 2010 11:21:26 +0200 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 28 Jun 2010 11:21:26 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: Policy for late/slow stabilizations Date: Mon, 28 Jun 2010 09:21:16 +0000 (UTC) Message-ID: References: <20100627150445.GA19456@Eternity> <20100627173834.230f0f76@snowcone> <20100627172233.GB1414@Mystical> <20100627184330.4888ce8a@snowcone> 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=UTF-8 X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.133 (House of Butterflies; GIT a971f44 branch-testing) Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 2f0b0c11-7ebb-4cf6-8c68-ad1c86e3fc93 X-Archives-Hash: f52dd3e7d299c89382869555e31df21b Ciaran McCreesh posted on Sun, 27 Jun 2010 18:43:30 +0100 as excerpted: > On Sun, 27 Jun 2010 20:22:33 +0300 > Markos Chandras wrote: >> > Which does Gentoo care about more: slightly increased convenience fo= r >> > most developers, or considerably increased inconvenience for users o= f >> > minority archs? >> >=20 >> I don't follow you. Increased convenience just for the devs? How? >=20 > Not having to keep old versions around for a few archs is slightly more > convenient for most people. >=20 > Having to deal with dropped keywords is a huge inconvenience for users > on minority archs. As already stated on the other sub-threads, that's not the point at all. = =20 Rather, it's a simple matter of letting an arch's stable tree dynamically= =20 and realistically adjust to the level of arch support they have. If the=20 stable set gets small enough, it's probably time to officially reduce the= =20 arch status to testing tree support only, not security supported, etc. =20 But well before that point, it's likely a core package set can be=20 maintained at stable, with perhaps certain arch-usage specific area stabl= e=20 support as well, while still being unrealistic to try to keep a stable=20 version of (nearly) all at-one-point-known-to-work packages available. If the arch support simply isn't there, it really is better to have that=20 reflected in the size of the stable set, such that users actually know=20 that and know what's being actively supported on their arch and what=20 isn't, than to try to fake it, which is what's going on now. It's not a=20 question of more convenience vs less, but of having arch keyword status=20 reflect arch support reality. That said, if there's not already a simple way to get the info out of VCS= =20 (perhaps there is, I don't know), archs may wish to maintain a list of=20 packages and versions that once were stable, along with comments on=20 specific destabilization reason (it didn't work with gcc-vX on that arch,= =20 for instance) if known, so it'll be somewhat easier to expand stable=20 coverage again if we happen to pickup a few new devs with a strong=20 interest in the arch. --=20 Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman