[gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Ulrich Mueller]

>>>>> On Wed, 3 Apr 2013, Ralph Sennhauser wrote:

> I feel strongly against starting with anything but EAPI 0. And I
> don't consider EAPI 4 old enough to start pestering maintainers
> about it.

> What we need is a live cycle of EAPIs to keep things manageable in
> the long run. We aren't under pressure to get rid of as many as
> possible ASAP. A simple scheme could be

> - EAPI becomes second latest
> - 5 years later repoman warns.
> - 2 years later repoman errors out.

To start with some numbers, here are the Portage versions
corresponding to EAPIs, together with their stabilisation dates:

   EAPI   approved     Portage version   stable on all arches
   (0)                 2.0.53 (*)        2005-12-26
   1                   2.1.3.19          2007-12-11
   2      2008-09-25   2.1.6.4           2009-01-08
   3      2010-01-18   2.1.7.17          2010-03-08
   4      2011-01-17   2.1.9.42          2011-03-17
   5      2012-09-20   2.1.11.31         2012-12-11

   (*) First EAPI aware Portage version

An EAPI becomes second latest when the following EAPI becomes stable
on all architectures. For example, EAPI 3 went stable at 2010-03-08
and EAPI 2 became second latest at the same day.

I agree with Francesco and Zac though, that support for 5 or even 7
year old systems isn't realistic at all. IMHO, we should go for an
intermediate time frame like 3 years (maybe 4, if we want to be very
conservative) for EAPI deprecation. This would limit the number of
EAPIs in active use to not more than four or five.

> With that scheme EAPI=0 would be due soon. As the "bump to latest
> eapi" policy isn't that old and seems to have only sunk in a about a
> year ago, and the myth of still requiring system packages to be
> EAPI=0 kept a lot of the tree at EAPI=0 for a long time. Fact is
> EAPI 0 ebuilds are still many, though the number started to crumble
> significantly lately. So waiting another year before starting
> actively warn might be appropriate.

I'd be a little more proactive and deprecate EAPIs 0 and 1 immediately
(which would correspond to the 4 years mentioned above). When doing a
version or revision bump, the ebuild should be updated to use a newer
EAPI. There can be exceptions, e.g. for security bumps.

> The important thing is for the council to declare intent and
> timeframe, so maintainers can plan far ahead. The other thing that
> became apparent from last discussion is that a slightly low EAPI
> shouldn't be a card blanch for zealots to touch packages they don't
> maintain or to file bugs about it.

Right, there's nothing wrong with existing ebuilds using EAPI 3 or 4,
unless you need a newer feature like subslots.

Ulrich