* Re: [gentoo-dev] GLEP 83 [v3]: EAPI deprecation
@ 2022-08-02 4:48 99% ` Sam James
0 siblings, 0 replies; 1+ results
From: Sam James @ 2022-08-02 4:48 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 4742 bytes --]
> On 1 Aug 2022, at 22:24, Duncan <1i5t5.duncan@cox.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@gentoo.org>
>> 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
>
>
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2022-07-11 19:25 [gentoo-dev] GLEP 83: EAPI deprecation Ulrich Mueller
2022-07-31 17:27 ` Ulrich Mueller
2022-07-31 21:26 ` [gentoo-dev] GLEP 83 [v3]: " Ulrich Mueller
2022-08-01 21:24 ` [gentoo-dev] " Duncan
2022-08-02 4:48 99% ` [gentoo-dev] " Sam James
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox