From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1KzhwN-0007pW-K3 for garchives@archives.gentoo.org; Tue, 11 Nov 2008 01:21:13 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 78D1DE0364; Tue, 11 Nov 2008 01:21:11 +0000 (UTC) Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) by pigeon.gentoo.org (Postfix) with ESMTP id 59AD1E0364 for ; Tue, 11 Nov 2008 01:21:11 +0000 (UTC) Received: from gw.thefreemanclan.net ([68.238.179.131]) by vms173005.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0KA500MU0AF96PN1@vms173005.mailsrvcs.net> for gentoo-dev@lists.gentoo.org; Mon, 10 Nov 2008 19:21:09 -0600 (CST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by gw.thefreemanclan.net (Postfix) with ESMTP id 6996C1759D58 for ; Mon, 10 Nov 2008 20:21:08 -0500 (EST) Date: Mon, 10 Nov 2008 20:21:08 -0500 From: Richard Freeman Subject: Re: [gentoo-dev] Proposal for how to handle stable ebuilds In-reply-to: <4918D0BC.50202@gentoo.org> To: gentoo-dev@lists.gentoo.org Message-id: <4918DE04.8010207@gentoo.org> 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-1; format=flowed Content-transfer-encoding: 7bit References: <20081110181334.GD7038@aerie.halcy0n.com> <4918D0BC.50202@gentoo.org> User-Agent: Thunderbird 2.0.0.17 (X11/20080929) X-Archives-Salt: bd025f8c-b5e5-467d-ad58-d2509bf08951 X-Archives-Hash: 70e083463a4e2ced3ab16bf62fb8f125 Jose Luis Rivero wrote: > I would prefer to analyze the causes of the slacker arch (manpower, > hardware, etc) and if we are not able to solve the problem by any way > (asking for new devs, buying hardware, etc) go for mark it as > experimental and drop all stable keywords. How is that better? Instead of dropping one stable package you'd end up dropping all of them. A user could accept ~arch and get the same behavior without any need to mark every other package in the tree unstable. An arch could put a note to that effect in their installation handbook. The user could then choose between a very narrow core of stable packages or a wider universe of experimental ones. I guess the question is whether package maintainers should be forced to maintain packages that are outdated by a significant period of time. Suppose something breaks a package that is 3 versions behind stable on all archs but one (where it is the current stable). Should the package maintainer be required to fix it, rather than just delete it? I suspect that the maintainer would be more likely to just leave it broken, which doesn't exactly leave things better-off for the end users. I'm sure the maintainers of qt/baselayout/coreutils/etc will exercise discretion on removing stable versions of these packages. However, for some obscure utility that next-to-nobody uses, does it really hurt to move from stable back to unstable if the arch maintainers can't keep up? I guess it comes down to the driving issues. How big a problem are stale packages (with the recent movement of a few platforms to experimental, is this an already-solved problem?)? How big of a problem do arch teams see keeping up with 30-days as (or maybe 60/90)? What are the practical (rather than theoretical) ramifications?