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 88CB4138010 for ; Thu, 30 Aug 2012 11:30:03 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C2510E055C; Thu, 30 Aug 2012 11:29:44 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 5711AE03E0 for ; Thu, 30 Aug 2012 11:29:06 +0000 (UTC) Received: from elia.localnet (g230212243.adsl.alicedsl.de [92.230.212.243]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: johu) by smtp.gentoo.org (Postfix) with ESMTPSA id B105433D83E for ; Thu, 30 Aug 2012 11:29:05 +0000 (UTC) From: Johannes Huber To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] EAPI usage Date: Thu, 30 Aug 2012 13:29:01 +0200 Message-ID: <1941775.YCGWEdgpfQ@elia> Organization: gentoo User-Agent: KMail/4.10 pre (Linux/3.5.2-gentoo; KDE/4.9.80; x86_64; git-; ) In-Reply-To: References: <1650487.RNHkTcOSMI@elia> 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-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Archives-Salt: 65ec3de2-7d37-4d57-876b-001f3ca1550a X-Archives-Hash: b941a925c262a6a27953bd241f69c989 > I can't say I'm a big fan of this. This requires forcing changes to > ebuilds that offer no actual benefit to either the maintainer or the > end-users (changes that actually have some benefit to either are > likely to be made anyway). The PM maintainers have chimed in that > there is no benefit to PM maintenance from this change. EAPI 0 is more readable than EAPI 4? No benefit for maintainer? No benefit for user who wants to read the ebuild? Realy? > So, I can't really see what the upside of such a policy is. > > The downsides are several - you're taking code that works and fiddling > with it, perhaps creating code that doesn't work. You're forcing that > development to take place in the newest EAPI, which is also the > version which the everybody has the least experience with (likely less > documentation online as well). devmanual is fine. > Developers have only a limited amount of time, and this will eat into > it. The result is likely to not be new shiny ebuilds that use the new > EAPIs, but rather old rusty ones that still use the old EAPI but also > which contain other bugs, since they don't get touched at all (since > touching them triggers the new policy). You dont need to touch the old ebuild, but if you are touching it for example a version bump, a bug fix etc you should be able to do the EAPI bump as long as you have done the ebuild quizzes ;) > For a real-world analogy - look at the result of well-intended laws > that require ADA compliance and such on building modifications. The > result is often stuff like kids taking classes in modular trailers and > such because in order to add an extension to the building you need to > bring the entire building up to code (and not just the new part). The > result isn't more elevators and ramps - but the use of hacked together > solutions to work around the policy. Examples? > If it ain't broke, don't fix it. Essential part of software development is refactoring to get the code in a modern state. > Now, if a maintainer actually needs a feature of a new EAPI, or an > ebuild contains a bug that can only be addressed by bumping it, then > by all means the maintainer should be revising the ebuild. Then there > is actually an upside to balance the cost. True. > Rich Greetings, -- Johannes Huber (johu) Gentoo Linux Developer / KDE Team GPG Key ID F3CFD2BD