> On 1 Aug 2022, at 22:24, Duncan <1i5t5.dun...@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 <u...@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 > >
signature.asc
Description: Message signed with OpenPGP
