* [gentoo-dev] Re: GLEP 83 [v3]: EAPI deprecation
@ 2022-08-01 21:24 99% ` Duncan
0 siblings, 0 replies; 1+ results
From: Duncan @ 2022-08-01 21:24 UTC (permalink / raw
To: gentoo-dev
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.)
> 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...
> 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
^ 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 99% ` [gentoo-dev] " Duncan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox