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 E372A138247 for ; Wed, 15 Jan 2014 00:48:02 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id F04E1E0933; Wed, 15 Jan 2014 00:47:54 +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 1074CE07ED for ; Wed, 15 Jan 2014 00:47:54 +0000 (UTC) Received: from [192.168.1.100] (c-68-49-223-78.hsd1.md.comcast.net [68.49.223.78]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mjo) by smtp.gentoo.org (Postfix) with ESMTPSA id F21F933F4CD for ; Wed, 15 Jan 2014 00:47:52 +0000 (UTC) Message-ID: <52D5DAB6.1000609@gentoo.org> Date: Tue, 14 Jan 2014 19:47:50 -0500 From: Michael Orlitzky User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] rfc: revisiting our stabilization policy References: <20140114213719.GA2684@laptop.home> <52D5B2CA.5030407@gentoo.org> <20140114223312.GA3337@laptop.home> <52D5BDAD.4030808@gentoo.org> <20140114231113.GA3393@laptop.home> In-Reply-To: <20140114231113.GA3393@laptop.home> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 19224626-2e80-4846-8514-279c3df992e8 X-Archives-Hash: ae80ac879043ef7ff3742721160b311b On 01/14/2014 06:11 PM, William Hubbs wrote: >> >> For users, both options are worse than the status quo. > > The first option would start reverting things back to ~ and users would > have to unmask them. > > The second option would introduce new things to stable which may not be > stable due to not being tested on the arch. > > The second option is worse than the first imo, that's why I didn't > propose it first. > > The status quo is not good, because we are forced to keep old, and > potentially buggy, versions of software around longer than necessary. So you're going to force stable users onto the unstable, untested version, which they could have done anyway if they wanted to. Strictly worse than the status quo (where it's optional).