From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 7CBFB138A1F for ; Mon, 27 Jan 2014 07:41:42 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4ECE7E0B36; Mon, 27 Jan 2014 07:41:35 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 6F335E0AE3 for ; Mon, 27 Jan 2014 07:41:34 +0000 (UTC) Received: from [192.168.11.20] (cpe-72-177-217-176.satx.res.rr.com [72.177.217.176]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steev) by smtp.gentoo.org (Postfix) with ESMTPSA id 8C36433E14B for ; Mon, 27 Jan 2014 07:41:33 +0000 (UTC) Message-ID: <1390808491.24681.46.camel@oswin.hackershack.net> Subject: Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy From: Steev Klimaszewski To: gentoo-dev@lists.gentoo.org Date: Mon, 27 Jan 2014 01:41:31 -0600 In-Reply-To: References: <20140119143157.72fc0e91@kruskal.home.chead.ca> <20140120014713.2cafc257@TOMWIJ-GENTOO> <20140123181242.GA17827@rathaus.eclipse.co.uk> <20140123201333.71e52bfc@TOMWIJ-GENTOO> <20140124104605.GA19957@rathaus.eclipse.co.uk> <20140124192641.5677cc51@TOMWIJ-GENTOO> <20140126045302.14342.qmail@stuge.se> <20140126185644.8251.qmail@stuge.se> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5 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-Transfer-Encoding: 7bit X-Archives-Salt: e5505b65-9683-477e-877d-5190e1cf9b5d X-Archives-Hash: 330c68fde345908d2bcc8932b9a67478 On Sun, 2014-01-26 at 16:35 -0500, Rich Freeman wrote: > On Sun, Jan 26, 2014 at 1:56 PM, Peter Stuge wrote: > > > > I don't think that's "completely optional" though, it sounds like a > > one-way function. If have ever stabilized a package once then must > > ensure a stable package forever. > > > > I think arbitrarily removing stable versions should also be an option, > > and I think package managers would be able to deal with that without > > much extra effort? > > Well, I think we certainly should be able to de-stabilize packages. > I've seen this happen in the past, especially when the need to not be > stable is inherent in the package itself (such as game clients that > need to be synchronized with servers - only one version will ever work > at any time buggy or not). > > Ideally this should really be the result of communication between the > maintainer and arch team. What we definitely don't want is a package > that gets stabilized, and then six months later the whole package is > back at ~arch, and then six months later there is a stable version > again, and so on. That just isn't, well, stable. > > However, if an arch team is feeling overwhelmed I'd strongly encourage > them to put out a bulletin telling maintainers to stop STABLEREQs for > non-system packages, or whatever other guidance they want to issue. > It has been pointed out that on these archs system packages often > don't work, so having those be stable at least lets them target > versions they want to fix up and lets users get a bootable system > without too much fuss. Falling back to a defensible position and all > that... > It's not necessarily the STABLEREQs stopping, some of the issues are (at least on some arches!) that some of the unstable software doesn't quite work properly anymore, and we are failing at communicating. And in those cases, we on the arch teams should definitely be pointing this out, and filing bugs so that the issues can be sorted. > But, nobody needs anybody's permission to do any of this. Ideally the > arch team should take the leadership to establish a policy on their > arch which is maintainable. If they don't do that, well, then > maintainers complain and we get threads like this one. The arch team > has the greatest interest in having the arch work - I'd strongly > support them in creating any policy for their arch that they can > follow-through on. > > Rich >