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 AEC4F138CE3 for ; Mon, 10 Feb 2014 12:39:55 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BF0A5E0BA3; Mon, 10 Feb 2014 12:39:47 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C03C9E0B9D for ; Mon, 10 Feb 2014 12:39:46 +0000 (UTC) Received: from [192.168.1.101] (unknown [114.91.160.149]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: patrick) by smtp.gentoo.org (Postfix) with ESMTPSA id 3465E33F5D7 for ; Mon, 10 Feb 2014 12:39:44 +0000 (UTC) Message-ID: <52F8C97D.4030403@gentoo.org> Date: Mon, 10 Feb 2014 20:43:41 +0800 From: Patrick Lauer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 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 To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] [RFC] Tightening EAPI rules Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: e58e8703-3614-4f8b-93ce-d30998d3aa3f X-Archives-Hash: 5f704c552fce90a9da7656a767542ac4 As previously discussed I would like to suggest that the number of tolerated EAPIs be reduced. There's been some discussion over the last 2+ years, with a weak consensus towards deprecating some EAPIs. What, when and how still isn't decided. So let's add some data so we have a better idea: EAPI Statistics: The daily updated stats [2] show a slow general trend down. There's historical data (well, just a few days right now at [3] The current sum of all ebuilds in tree adds up to ~10% EAPI 1+2 EAPI0 is still surprisingly big around ~15% EAPI3 is about as big as EAPI2 at around ~7% According to [1] EAPI 1 and 2 are deprecated. At the time EAPI 0 was in limbo as toolchain required it (What's the current status of toolchain on that?) I suggest the following change: [ EAPI 0 depends on toolchain's acceptance. Should toolchain agree then adding EAPI0 ebuilds becomes forbidden] Adding EAPI 1 and 2 ebuilds is forbidden. (repoman-fatal) EAPI 3 becomes deprecated (like 1 and 2 are now) Adding EAPI 3 ebuilds is forbidden in now +3 months EAPI 4 becomes deprecated when/if there's a new EAPI allowed in-tree (EAPI 6, most likely) EAPI 5 is the recommended default. Rationale: More than two supported EAPIs is an unneeded burden on developers. Thus 4 will be deprecated when post-5 becomes added. There's no immediate need to forbid the antepenultimate EAPI immediately. The goal of this upgrade policy is that we can accelerate the expiration of old EAPIs - EAPI 2 happened at some point in 2008, I think (or 2009?) and we still carry five-year-old cruft around. Given the percentages - EAPI 1 can be "cleaned out" by a single motivated individual. It's almost gone. EAPI 2 and 3 will take a few months at least, even if there's a coordinated effort to migrate. EAPI 0 is as big as 2 and 3 together, and depends on toolchain herd's actions. It'll still be around for a looong time. (Given the current rate of change, plus repoman support, plus people actively working on pruning it, I would assume it'll take at least a year, more likely two) In other words, even if we go for the "fastest" option you won't see any revolutionary change :) Please no bikeshedding, Patrick [1] https://www.gentoo.org/proj/en/council/meeting-logs/20130409.txt [2] http://packages.gentooexperimental.org/eapi-stats.txt [3] http://packages.gentooexperimental.org/eapi-history/