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/
