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 910BF138247 for ; Wed, 15 Jan 2014 01:36:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DDD64E0A8F; Wed, 15 Jan 2014 01:36:13 +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 E0CA9E0A65 for ; Wed, 15 Jan 2014 01:36:12 +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 C88E133F135 for ; Wed, 15 Jan 2014 01:36:11 +0000 (UTC) Message-ID: <52D5E60A.80600@gentoo.org> Date: Tue, 14 Jan 2014 20:36:10 -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> <52D5DAB6.1000609@gentoo.org> <20140115020802.700b1568@TOMWIJ-GENTOO> <52D5E03C.3010900@gentoo.org> <20140115022337.4336618d@TOMWIJ-GENTOO> In-Reply-To: <20140115022337.4336618d@TOMWIJ-GENTOO> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: a8260788-ad52-4545-a0df-146ca508689b X-Archives-Hash: 124abc0cfe478a82d0d6f935673d2baf On 01/14/2014 08:23 PM, Tom Wijsman wrote: > On Tue, 14 Jan 2014 20:11:24 -0500 > Michael Orlitzky wrote: > >> On 01/14/2014 08:08 PM, Tom Wijsman wrote: >>> >>> This is under the assumption that the user knows of the state of the >>> stabilization worsening; if the user is unaware of that change, the >>> "could have done anyway" might be less common and first something >>> bad would need to happen before they realize the worsened >>> stabilization. >>> >> >> If I don't realize it, it ain't broke. > > So, you're going to wait for corruption, a security breach or something > along those lines to happen first? I will wait for them to be *known*. Security stabilizations are already treated special, so while they'd make a nice example here you don't get to invoke them =) It's highly unlikely that one day a stable piece of software is just going to start corrupting data randomly when some other stable package is updated. Why? Because arch testers have to test them before they go stable! It's even more unlikely that upgrading to untested stuff would be safer than staying put, which is really all I care about given a choice between the two. For really bad cases like data corruption we already have procedures that allow quick stabilization ("reasonable amount of time..."). All we're really talking about here is forcing me to upgrade to an unstable package for some features or bugfixes I don't care about.