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 D9133138247 for ; Wed, 15 Jan 2014 00:50:38 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D7CB3E09A5; Wed, 15 Jan 2014 00:50:33 +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 005E0E094E for ; Wed, 15 Jan 2014 00:50:32 +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 23CA333EEAE for ; Wed, 15 Jan 2014 00:50:32 +0000 (UTC) Message-ID: <52D5DB56.8070508@gentoo.org> Date: Tue, 14 Jan 2014 19:50:30 -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> <20140115011341.6c8395bf@TOMWIJ-GENTOO> In-Reply-To: <20140115011341.6c8395bf@TOMWIJ-GENTOO> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 1e0fa33e-4f91-4b07-8f8e-11147e0d9363 X-Archives-Hash: 24a6a5bc43bc7e76d2f13bf9aaaeb1d3 On 01/14/2014 07:13 PM, Tom Wijsman wrote: >> >> For users, both options are worse than the status quo. > > When you do nothing then things are bound to get worse, under the > assumption that manpower doesn't change as well as the assumption that > the queue fills faster than stabilization bugs get added to it. > > As a result of this, stable will eventually become broken. It is up to > you as well as us whether to consider it to be broken right now. Will > it be in a month from now? What about in a year? > > Will we wait for hell? Or try to prepare and/or fix it now? > > Maybe there are other options if these can be deemed as being worse. > As I mentioned in a reply to William, right now I can decide when stuff is broken and keyword the newer versions. The proposal is to force me onto the new versions, which is strictly worse from my perspective. The whole issue of how much it sucks that stable is lagging is orthogonal.