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 0C00A138247 for ; Wed, 15 Jan 2014 12:51:59 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B8096E0B45; Wed, 15 Jan 2014 12:51:51 +0000 (UTC) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id CB0A6E0B3C for ; Wed, 15 Jan 2014 12:51:50 +0000 (UTC) Received: by mail-ie0-f175.google.com with SMTP id tp5so1985218ieb.20 for ; Wed, 15 Jan 2014 04:51:50 -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:cc:content-type:content-transfer-encoding; bh=5ofFL2DmeFG9ES7uHCE33hI2UzEVHYpY9VFH7GmyFCk=; b=Qkl3A5x4fn60LW2j5MGFQE6nOLvyfmDxttS27qRWXkI/Qhi1oSBv52W/QK8asfTjxo O9YDYT20MYI20Wo3weTU3vJkql06gKVQoAl7kpJAENOfde6sd06FDQ8aixuHnXgtgHVZ nPQKbI+ovtlrdG0R0hi4VQRsYwIe5H0MehoDiTb/9l+mXCkfm6rG72mTxnXpvz7gSh+D SaEyK+WPLl+EAKAZg3juGs62tW9pDoj/KegYSpn2LuxnHSxKGZVYUTdfDzaP/9+oR/Ug WxnFQ7JovA0Pbe5nmvRhNJWVOJwlWIXrEhdD2hHuXmalSo4b3S64qzdF/TYCDgJpK0jb EBmg== 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.50.2.74 with SMTP id 10mr2468781igs.32.1389790310013; Wed, 15 Jan 2014 04:51:50 -0800 (PST) Sender: freemanrich@gmail.com Received: by 10.64.73.99 with HTTP; Wed, 15 Jan 2014 04:51:49 -0800 (PST) In-Reply-To: <20140115105415.5df3cdac@pomiot.lan> References: <20140114213719.GA2684@laptop.home> <20140115105415.5df3cdac@pomiot.lan> Date: Wed, 15 Jan 2014 07:51:49 -0500 X-Google-Sender-Auth: kLfjUX_TZ1_LxQLANkuPPFg0Ueg Message-ID: Subject: Re: [gentoo-dev] rfc: revisiting our stabilization policy From: Rich Freeman To: gentoo-dev Cc: William Hubbs Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 80661b2f-4a51-47bd-b327-ab6f3c2064c9 X-Archives-Hash: c14bf9dd2346c5e38a9e92e1ce988a1e On Wed, Jan 15, 2014 at 4:54 AM, Micha=C5=82 G=C3=B3rny = wrote: > > 2) has to add package.accept_keywords entry for the package. Which > means turning a pure stable system into an unsupported mixed-keyword > system. As opposed to an unsupported pure stable system or an unsupported pure unstable system? I doubt anybody runs a pure stable system, and if they do I doubt their experience is much different from those who run mixed keywords. Of course, having random system packages drop stable keywords from time to time isn't going to help anything in that department. Obviously maintainers should keep stable system packages around as long as they can. However, there needs to be some way to deal with cases where their stabilization gets held up on a major arch. If we don't have the manpower to stabilize newer versions, what makes anybody think that maintainers have the manpower to "support" ancient versions? The have our cake and eat it too solution is to obtain more manpower. That should be done without question, but for whatever reason it never actually happens, so we need to think about what the alternative is. If talking about it scares more people into volunteering so that it isn't necessary all the better... Given constrained manpower the options basically are some variation on: 1. Status quo - for some packages stable gets REALLY old, and likely has problems that maintainers ignore. You can't force somebody to maintain something any more than you can force somebody to test something. 2. We become more liberal with stabilizing newer versions. Lots of variations on this, but the bottom line is that packages get stabilized that would otherwise not be. 3. We drop stable keywords on packages. Lots of variations on this as well, but the result is mixed-arch systems or dropping stable for the whole arch. I don't think #1 is really the answer - it just results in less-visible problems and a stable that is probably works worse than either #2 or #3 would yield. #2 has the advantage that it gives us more control over what gets installed on stable systems and you don't end up with mixed keywords. The downside to #2 is that the user doesn't have as much visibility into which packages are "really" stable. Maybe an in-between quality tier would help (if you're going to run a mixed keyword system, at least use this version). #3 has the advantage that it makes the problem directly visible to the user. However, the solution ends up being entirely user-discretion. Some users end up on ~arch for life, others do it version-by-version in which case they end up on various versions. Personally I run stable and when I need to run unstable on a package I tend to use