1 |
> > |
2 |
> > * Mainly, less stuff to memorize. I'll be throwing a party on the day when |
3 |
> > the last EAPI=0 ebuild is gone. (In the retirement home, probably.) |
4 |
> |
5 |
> This is the argument made by others about the cognitive overhead of |
6 |
> remembering all the EAPI differences. If the packages are untouched |
7 |
> for ages and don't require maintenance, my claim is that there is no |
8 |
> cognitive load to begin with. |
9 |
|
10 |
That stops the moment something could use a USE- or slot operator dependency |
11 |
(because of a tree-wide change that also affects the old package). Then the |
12 |
EAPI bump suddenly becomes urgent (and a minor QA-like commit becomes a major |
13 |
change). |
14 |
|
15 |
And no bugs probably just means no users that could file bugs. We really need |
16 |
something like gentoostats... |
17 |
|
18 |
> > [Interestingly, as long as no specific efforts are made, the number of |
19 |
> > ebuilds in all deprecated EAPI decreases roughly equally and |
20 |
> > exponentially. That means the probability of any old ebuild to be removed |
21 |
> > within a certain time interval is a constant as function of time...] |
22 |
> |
23 |
> This is a great point in favor of *not* bothering to proactively bump EAPI. |
24 |
|
25 |
Not really. It's an asymptotic curve. *If* you want to have it gone |
26 |
*completely* at some point, you have to start actively working on that. The |
27 |
only question is when, earlier or later... |
28 |
|
29 |
I'd guess having an EAPI approach <~ 1% of the tree is probably as good as any |
30 |
other criterion. |
31 |
|
32 |
[[What is interesting but offtopic is that the exponential decay is the same |
33 |
for a long timeframe, see [*] third panel... the downward slope of the white |
34 |
line for EAPI=0 barely changes, and the other EAPI run parallel to it as long |
35 |
as nothing special happens... This means that Gentoo isn't dying after all, |
36 |
since the same developer activity takes place!]] |
37 |
|
38 |
[*] https://www.akhuettel.de/~huettel/plots/eapi.php |
39 |
|
40 |
-- |
41 |
Andreas K. Hüttel |
42 |
dilfridge@g.o |
43 |
Gentoo Linux developer |
44 |
(council, toolchain, perl, libreoffice, comrel) |