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 351C41381F4 for ; Wed, 15 Aug 2012 00:04:26 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BED0721C04E for ; Wed, 15 Aug 2012 00:04:25 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 8F71921C154 for ; Tue, 14 Aug 2012 22:29:07 +0000 (UTC) Received: from [192.168.26.5] (ip98-164-193-252.oc.oc.cox.net [98.164.193.252]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: zmedico) by smtp.gentoo.org (Postfix) with ESMTPSA id 156DF1B403D for ; Tue, 14 Aug 2012 22:29:07 +0000 (UTC) Message-ID: <502AD131.6000406@gentoo.org> Date: Tue, 14 Aug 2012 15:29:05 -0700 From: Zac Medico User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:14.0) Gecko/20120802 Thunderbird/14.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org MIME-Version: 1.0 To: gentoo-project@lists.gentoo.org Subject: Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC References: <20120807191736.GF49719@gentoo.org> <20120814223556.780b481d@googlemail.com> <502AC963.5040000@gentoo.org> <201208150022.00567.dilfridge@gentoo.org> In-Reply-To: <201208150022.00567.dilfridge@gentoo.org> X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 04a577f4-6249-47c0-b2ea-ad4a056fcac9 X-Archives-Hash: 7dfa4732c444c2365577e2b6aab21d7a On 08/14/2012 03:21 PM, Andreas K. Huettel wrote: > Am Dienstag, 14. August 2012, 23:55:47 schrieb Zac Medico: >> It seems like there's some confusion here. Approving a new EAPI and >> deciding to use a new EAPI in a given profile are two entirely different >> things. If we want to us a new EAPI in a profile, we just have to deploy >> it such that users are only exposed to that profile when they >> consciously running `eselect profile` (and they can always revert back >> to the previous profile if it turns out that their installed package >> manager doesn't support the new profile). > > Yeah but... either > 1) we use such an obscure profile that noone actually notices the change, or > 2) we try to change something in the "big, well-known profiles", > and then we're back at the start. > > So what good is including a feature in a new profile if there is no way to > make it visible to "the users" in general? You do it in all the new profiles, and deprecate the old profiles. Users see the profile deprecation notice (or news item or other announcement) and upgrade their profile. > Also, in this particular case, "stable use masking" is useful because it makes > stabilization possible/simpler in cases where otherwise this would lead to > broken dependencies (stable depending on ~arch). If only one small sub-profile > provides the feature, we lose its whole advantage. Yeah, that's why I'm saying to do it in *all* new profiles and deprecate the old ones. -- Thanks, Zac