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 62326138A1F for ; Sun, 26 Jan 2014 21:35:35 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 83813E0DB9; Sun, 26 Jan 2014 21:35:30 +0000 (UTC) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 8977BE0D81 for ; Sun, 26 Jan 2014 21:35:29 +0000 (UTC) Received: by mail-qa0-f41.google.com with SMTP id w8so6461513qac.0 for ; Sun, 26 Jan 2014 13:35:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=I4AgvieBFtPlLUa11Kxbxb+pwt+UZFGFG4tyRmKBZjI=; b=MKfMLLvtBe1BvjJIiwvR1wpDsVh792gdXDWYrgEHGRW8V+5zHgyg2vMu3/kHYQjCYj GUea6HD2gZp2ndgPhhs9CrM9T4qK4imtw+5TPduLzY0lHG2oUlSrWy7F+R+nzHcg8sN6 Z6hIX5FLugRV634FZpyxJT9C0ksBrSO6XvBULS7i9xj2bhnEhcWn1lnJgeP4ONlA/cyJ 7+5ix0TIh+I9JOtrHdp6CqNzuRBvbOzk8uKjxBRqUwLLVyLUbhSLkdnaUF7/pAHCPb4v Xpvh30a9t25REgVebKaNDDzPN/tEtOgDs43WYQyLVu3XeXEIOcOlKJ99sWvhqZM6oFbw 6/Rg== 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 X-Received: by 10.224.124.74 with SMTP id t10mr37848461qar.40.1390772128669; Sun, 26 Jan 2014 13:35:28 -0800 (PST) Sender: freemanrich@gmail.com Received: by 10.140.49.233 with HTTP; Sun, 26 Jan 2014 13:35:28 -0800 (PST) In-Reply-To: <20140126185644.8251.qmail@stuge.se> 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> Date: Sun, 26 Jan 2014 16:35:28 -0500 X-Google-Sender-Auth: GKUqePaU19cgeyBUqADKsH1weQo Message-ID: Subject: Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy From: Rich Freeman To: gentoo-dev Content-Type: text/plain; charset=ISO-8859-1 X-Archives-Salt: 5a7f7a8c-2626-40c1-a39a-93292ec8baf5 X-Archives-Hash: 02352d869255fb5aa96d64176e169264 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... 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