Re: [gentoo-dev] Is removing old EAPIs worth the churn?

["Andreas K. Huettel" <dilfridge@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 1991 bytes --]

> > 
> > * Mainly, less stuff to memorize. I'll be throwing a party on the day when
> > the last EAPI=0 ebuild is gone. (In the retirement home, probably.)
> 
> This is the argument made by others about the cognitive overhead of
> remembering all the EAPI differences. If the packages are untouched
> for ages and don't require maintenance, my claim is that there is no
> cognitive load to begin with.

That stops the moment something could use a USE- or slot operator dependency 
(because of a tree-wide change that also affects the old package). Then the 
EAPI bump suddenly becomes urgent (and a minor QA-like commit becomes a major 
change).

And no bugs probably just means no users that could file bugs. We really need 
something like gentoostats...

> > [Interestingly, as long as no specific efforts are made, the number of
> > ebuilds in all deprecated EAPI decreases roughly equally and
> > exponentially. That means the probability of any old ebuild to be removed
> > within a certain time interval is a constant as function of time...]
> 
> This is a great point in favor of *not* bothering to proactively bump EAPI.

Not really. It's an asymptotic curve. *If* you want to have it gone 
*completely* at some point, you have to start actively working on that. The 
only question is when, earlier or later... 

I'd guess having an EAPI approach <~ 1% of the tree is probably as good as any 
other criterion.

[[What is interesting but offtopic is that the exponential decay is the same 
for a long timeframe, see [*] third panel... the downward slope of the white 
line for EAPI=0 barely changes, and the other EAPI run parallel to it as long 
as nothing special happens... This means that Gentoo isn't dying after all, 
since the same developer activity takes place!]]

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

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]