> > > > * 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 dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, perl, libreoffice, comrel)
signature.asc
Description: This is a digitally signed message part.
