From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1KqSJR-000085-A1 for garchives@archives.gentoo.org; Thu, 16 Oct 2008 12:50:45 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5621CE03E9; Thu, 16 Oct 2008 12:50:42 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id E56AEE03E9 for ; Thu, 16 Oct 2008 12:50:41 +0000 (UTC) Received: from jewel (5.Red-83-33-254.dynamicIP.rima-tde.net [83.33.254.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 689EB64DBC for ; Thu, 16 Oct 2008 12:50:37 +0000 (UTC) Received: by jewel (nbSMTP-1.00) for uid 1001 (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) yoswink@gentoo.org; Thu, 16 Oct 2008 14:50:38 +0200 (CEST) Date: Thu, 16 Oct 2008 14:50:34 +0200 From: Jose Luis Rivero To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Stabilize ebuilds which use EAPIs only supported by ~arch PMs Message-ID: <20081016125034.GA22095@gentoo.org> Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <20081014000340.GA5494@gentoo.org> <20081014003834.GE23706@comet> <20081014085939.GA5520@gentoo.org> <20081014181712.1a5ad3c7@sheridan.genone.homeip.net> 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081014181712.1a5ad3c7@sheridan.genone.homeip.net> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Archives-Salt: 5b5df08b-f5e8-44ad-8825-138eb9e7d109 X-Archives-Hash: 4ab65c9fd7cae289396e9b63bb183e04 On Tue, Oct 14, 2008 at 06:17:12PM +0200, Marius Mauch wrote: > On Tue, 14 Oct 2008 10:59:39 +0200 > Jose Luis Rivero wrote: > > > > EAPI-2 to EAPI-0 could imply lot of changes (not talking about what is > > going to happen when we release new and more feature rich EAPIs), and > > changes usually come with bugs. The ebuild is committed directly to > > stable implies bugs in stable, which for me is a no-go. > > Assuming the ebuild changes between foo-1 and foo-2 are mainly due to > the change from EAPI=0 to EAPI=2 (which I'd expect to be true in many > cases) you could just reuse the foo-1 ebuild for foo-3. > > If there are major differences between foo-1 and foo-2 not related to > the EAPI change then the maintainer probably didn't want foo-2 to > become stable anytime soon, so it's at least questionable if foo-3 > should go straight to stable in the first place. I was talking about this case, were foo-2 is in testing and is not ready for stable. It's not questionable to go directly to stable if security is involved in the process. > And adding a new version directly to stable always comes with a risk, > you can't eliminate that completely. It's all about risk assessment, > and how much work you're willing to do or time you want to spend to > minimize the risk. Agree. The question bringing here is: how can we minimize the risk if this situation appear, where we have an EAPI change between ebuilds in stable and testing branch and EAPI in testing can only be managed by testing PMs. > In the end at least one of the above solutions should work in > almost every case. It might sometimes cause a bit more work than a bump > that doesn't involve any EAPI changes, but that's life. Well, when I think about having to revert eapi changes or having to make own backports and apply these solutions directly to stable because we are using some features not supported by stable PMs, I have doubts if it wouldn't be better to avoid these situations and wait for the PMs to be stable. > If you have a real case where both suggested solutions aren't > realistic I'd like to hear about it, otherwise I think we're wasting > time making up solutions for a non-existant problem It's not about realistic, just about how risky the solutions could be to be in our stable branch. Perhaps I'm being very pessimistic. Leave the question here and we will see what happen in the future. We'll back to this if needed. Thanks. -- Jose Luis Rivero Gentoo/Doc Gentoo/Alpha