Re: [gentoo-project] Call for agenda items - council meeting 2020-03-08

[Ulrich Mueller]

>>>>> On Mon, 02 Mar 2020, Michał Górny wrote:

> Following the discussion within the QA team, I'd like to ask the Council
> to clarify whether EAPI 4 ban applies to revision bumps as a result of
> dependency changes?

> I think the key point in banning EAPIs is that the maintainer (or
> generally, someone caring about the package in question) should be
> responsible for the EAPI bump.  I don't think anybody should be forced
> to do that when in middle of large batch of changes (read: when I only
> touch the package because it's blocking me).

> In this particular case, I'm thinking of revbumps due to dependency
> changes.  Say, if I do a change in a dependency *I* maintain, and have
> to fix a large number of revdeps, I don't think it's fair to expect me
> to EAPI-bump some packages I don't maintain.  The main difference is
> that we're talking of dep change + revbump that can be linted via
> pkgcheck/repoman vs. EAPI bump that needs full scale testing.

EAPIs are being banned after a deprecation period, which typically is
two years. So I guess one can expect packages that run into the ban not
to be very actively maintained.

Looking at the plots [1] (especially the third plot from the top),
I don't see any change in slope for EAPI 0 in 2016-01 or for EAPI 4
in 2018-04. So arguably, the "banned" state doesn't give any additional
incentive to update an ebuild, as compared to the "deprecated" state.
After your proposed change, the difference between the two states would
be even more blurred.

Maybe we should revisit the concept, and ban EAPIs only when their last
ebuild has left the tree, i.e., when the EAPI is added to eapis-banned
in layout.conf?

Ulrich

[1] https://www.akhuettel.de/~huettel/plots/eapi.php