Re: [gentoo-dev] GLEP 83 [v3]: EAPI deprecation

[Sam James]

> On 1 Aug 2022, at 22:24, Duncan <1i5t5.duncan@×××.net> wrote:
>
> Ulrich Mueller posted on Sun, 31 Jul 2022 23:26:13 +0200 as excerpted:
>
>> Update v3
>
> One language thing and two possible clarifications.
>
>> ---
>> GLEP: 83 Title: EAPI deprecation
>> Author: Ulrich Müller <ulm@g.o>
>> Type: Informational Status: Draft
>> Version: 1
>> Created: 2022-06-30
>> Last-Modified: 2022-07-31
>> Post-History: 2022-07-11, 2022-07-31
>> Content-Type: text/x-rst
>> ---
>
>> Specification =============
>>
>> A *deprecated EAPI* is no longer required for the upgrade path of users'
>> systems.  Its use is discouraged, and tools like pkgcheck will warn
>> about this [#COUNCIL-20130409]_.
>>
>> A *banned EAPI* must no longer be used, neither for new ebuilds, nor for
>> updating of existing ebuilds [#COUNCIL-20140311]_.
>>
>> The Gentoo Council will deprecate an EAPI when
>>
>> * two newer Council-approved EAPIs are supported by the stable version
>>  of Portage, and
>> * one of them has been supported for 24 months.
>>
>> The Gentoo Council will ban a deprecated EAPI when
>>
>> * 24 months have passed since its deprecation, and * it is used by fewer
>> than 5 % of ebuilds in the Gentoo repository.
>
> The first possible clarification fits here (I think).  Something like:
>
> This GLEP is intended as a policy reference guide for EAPI minimum effective
> times.  Despite the statistical qualifications listed here no EAPI
> will be deprecated or banned without specific Gentoo Council action.
>
> (While this is implied by the "Gentoo Council will..." wording, making it
> explicit could prevent later confusion/controversy.)

If anything, this might make things more confusing, given it implies
the Council can deviate if it wants.

>
>> EAPIs used in profiles are outside the scope of this GLEP.
>>
>>
>> Rationale =========
>>
>> Timing of EAPI deprecation is a trade-off between different factors.
>> On the one hand, the total number of EAPIs in active use should be
>> limited; this will prevent the learning curve for new developers and
>> contributors from becoming too steep and will help to reduce code
>> complexity, e.g. in eclasses.
>
> The language point:
>
> Am I the only one for whom the omission of "from" makes the sentence read
> smoother?  (Maybe it's a regional English thing?)
>
> ; this will prevent the learning curve [...] from becoming too steep...
>
> ; this will prevent the learning curve [...] becoming too steep...
>

It reads slightly smoother without "from" but I didn't notice it when
reading myself.

I guess we can drop it.

>> On the other hand, an upgrade path to a stable system is guaranteed for
>> one year, plus limited support for systems that are outdated more than a
>> year [#COUNCIL-20091109]_.  Therefore, previous EAPIs are still required
>> during that time.  A period of 24 months before deprecation has been
>> chosen, which is more than the required minimum and will allow projects
>> to support a longer upgrade path.
>>
>> Requiring two newer EAPIs before deprecation will allow ebuilds that are
>> otherwise seldom updated to be bumped to the next but one EAPI
>> immediately.
>
>> A delay of 24 months between deprecation and ban will give ebuild
>> authors enough time to update.  This is especially relevant for overlays
>> and downstream distributions.  An additional requirement for banning an
>> EAPI is that fewer than 5 % of ebuilds are using the EAPI in question.
>> This requirement is defined to help keep the number of ebuild updates
>> (and bug reports requesting them) managable, as a banned EAPI is
>> sufficient reason for updating an ebuild.
>
> The second possible clarification seems to fit about here, but may require
> a bit of adjustment to the text above it.
>
> The two 24-month times are effectively additive, yielding a total 48 months
> minimum between addition of an EAPI and banning of the previous one.  Given
> past EAPI history of at minimum a year between EAPI introductions that should
> yield a minimum three years of active EAPI life before deprecation, one year
> minimum as the newest EAPI plus two years before deprecation, plus two years
> of deprecation, for five years total EAPI life before ban.
>
> (This isn't entirely necessary but makes explicit the answer to one of my first
> questions reading the proposal.  YMMV.  I debated spec vs rational, but decided
> rational was a better fit.)
>
> --
> Duncan - List replies preferred.   No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master."  Richard Stallman
>
>