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 EDA4E138010 for ; Thu, 30 Aug 2012 10:58:31 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 44D76E0540; Thu, 30 Aug 2012 10:58:13 +0000 (UTC) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) by pigeon.gentoo.org (Postfix) with ESMTP id 71C1CE001D for ; Thu, 30 Aug 2012 10:57:26 +0000 (UTC) Received: by vcbfl17 with SMTP id fl17so1763835vcb.40 for ; Thu, 30 Aug 2012 03:57:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=AwHTzSENmWyPbkvfAaPqg0YK1XmHHLXvfEQlXTl6KyY=; b=R185cQGQ2dLnfJWeU1MxH4Gvz+X7R4mH+GiELIxsEPe1N+CvlRxUYg4tyxAT3O9Cv7 Oz8u4JhzeMrwVUzXQTCHHX289s7XSKAZeKCVWGkyVW/yZlHs6ZRloJ4x2XjxAwjNkm5d bZXYQXEn697hg+M1gAZqWn1nbhsS6TTzn5EYtuz9WGJfkgQuetwV5GL84WRZN0EsWlEJ bYkTIais7LD9lwGTB99NahP1tMpZwgOJ3IP8kn2gClopXw2+XEJ2I9NGpMu9FfC8ex+d whU5Eo57Zrv6d7UDol0dYXO7x6+GwrnNlewwF1rFr0I4DyJVLetWMZCYH8tVaYWouXYC Xlaw== 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 Received: by 10.52.70.116 with SMTP id l20mr2292964vdu.74.1346324245889; Thu, 30 Aug 2012 03:57:25 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.220.5.195 with HTTP; Thu, 30 Aug 2012 03:57:25 -0700 (PDT) In-Reply-To: <1650487.RNHkTcOSMI@elia> References: <1650487.RNHkTcOSMI@elia> Date: Thu, 30 Aug 2012 06:57:25 -0400 X-Google-Sender-Auth: uGkpIE62dmfHjbbX1MnhaiwpEkQ Message-ID: Subject: Re: [gentoo-dev] EAPI usage From: Rich Freeman To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=ISO-8859-1 X-Archives-Salt: 2ccdba2d-d66b-49ab-a635-aaa324f46545 X-Archives-Hash: f7996e23e3a7db695be597039674e7ae On Thu, Aug 30, 2012 at 6:28 AM, Johannes Huber wrote: >> scarabeus suggested the change "dev should use latest eapi when bumping" >> to "dev must use latest eapi when bumping if not forbidden by eclasses". >> He was asked to bring it up on the mailing lists, to get a better >> definition of when what EAPI should be used. > > I raised the issue through scarabeus, as in my opinion there is no reason to > not use latest EAPI. So please discuss. > 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. 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). 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). 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. If it ain't broke, don't fix it. 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. Rich