1 |
Ulrich Mueller posted on Sun, 31 Jul 2022 23:26:13 +0200 as excerpted: |
2 |
|
3 |
> Update v3 |
4 |
|
5 |
One language thing and two possible clarifications. |
6 |
|
7 |
> --- |
8 |
> GLEP: 83 Title: EAPI deprecation |
9 |
> Author: Ulrich Müller <ulm@g.o> |
10 |
> Type: Informational Status: Draft |
11 |
> Version: 1 |
12 |
> Created: 2022-06-30 |
13 |
> Last-Modified: 2022-07-31 |
14 |
> Post-History: 2022-07-11, 2022-07-31 |
15 |
> Content-Type: text/x-rst |
16 |
> --- |
17 |
|
18 |
> Specification ============= |
19 |
> |
20 |
> A *deprecated EAPI* is no longer required for the upgrade path of users' |
21 |
> systems. Its use is discouraged, and tools like pkgcheck will warn |
22 |
> about this [#COUNCIL-20130409]_. |
23 |
> |
24 |
> A *banned EAPI* must no longer be used, neither for new ebuilds, nor for |
25 |
> updating of existing ebuilds [#COUNCIL-20140311]_. |
26 |
> |
27 |
> The Gentoo Council will deprecate an EAPI when |
28 |
> |
29 |
> * two newer Council-approved EAPIs are supported by the stable version |
30 |
> of Portage, and |
31 |
> * one of them has been supported for 24 months. |
32 |
> |
33 |
> The Gentoo Council will ban a deprecated EAPI when |
34 |
> |
35 |
> * 24 months have passed since its deprecation, and * it is used by fewer |
36 |
> than 5 % of ebuilds in the Gentoo repository. |
37 |
|
38 |
The first possible clarification fits here (I think). Something like: |
39 |
|
40 |
This GLEP is intended as a policy reference guide for EAPI minimum effective |
41 |
times. Despite the statistical qualifications listed here no EAPI |
42 |
will be deprecated or banned without specific Gentoo Council action. |
43 |
|
44 |
(While this is implied by the "Gentoo Council will..." wording, making it |
45 |
explicit could prevent later confusion/controversy.) |
46 |
|
47 |
> EAPIs used in profiles are outside the scope of this GLEP. |
48 |
> |
49 |
> |
50 |
> Rationale ========= |
51 |
> |
52 |
> Timing of EAPI deprecation is a trade-off between different factors. |
53 |
> On the one hand, the total number of EAPIs in active use should be |
54 |
> limited; this will prevent the learning curve for new developers and |
55 |
> contributors from becoming too steep and will help to reduce code |
56 |
> complexity, e.g. in eclasses. |
57 |
|
58 |
The language point: |
59 |
|
60 |
Am I the only one for whom the omission of "from" makes the sentence read |
61 |
smoother? (Maybe it's a regional English thing?) |
62 |
|
63 |
; this will prevent the learning curve [...] from becoming too steep... |
64 |
|
65 |
; this will prevent the learning curve [...] becoming too steep... |
66 |
|
67 |
> On the other hand, an upgrade path to a stable system is guaranteed for |
68 |
> one year, plus limited support for systems that are outdated more than a |
69 |
> year [#COUNCIL-20091109]_. Therefore, previous EAPIs are still required |
70 |
> during that time. A period of 24 months before deprecation has been |
71 |
> chosen, which is more than the required minimum and will allow projects |
72 |
> to support a longer upgrade path. |
73 |
> |
74 |
> Requiring two newer EAPIs before deprecation will allow ebuilds that are |
75 |
> otherwise seldom updated to be bumped to the next but one EAPI |
76 |
> immediately. |
77 |
|
78 |
> A delay of 24 months between deprecation and ban will give ebuild |
79 |
> authors enough time to update. This is especially relevant for overlays |
80 |
> and downstream distributions. An additional requirement for banning an |
81 |
> EAPI is that fewer than 5 % of ebuilds are using the EAPI in question. |
82 |
> This requirement is defined to help keep the number of ebuild updates |
83 |
> (and bug reports requesting them) managable, as a banned EAPI is |
84 |
> sufficient reason for updating an ebuild. |
85 |
|
86 |
The second possible clarification seems to fit about here, but may require |
87 |
a bit of adjustment to the text above it. |
88 |
|
89 |
The two 24-month times are effectively additive, yielding a total 48 months |
90 |
minimum between addition of an EAPI and banning of the previous one. Given |
91 |
past EAPI history of at minimum a year between EAPI introductions that should |
92 |
yield a minimum three years of active EAPI life before deprecation, one year |
93 |
minimum as the newest EAPI plus two years before deprecation, plus two years |
94 |
of deprecation, for five years total EAPI life before ban. |
95 |
|
96 |
(This isn't entirely necessary but makes explicit the answer to one of my first |
97 |
questions reading the proposal. YMMV. I debated spec vs rational, but decided |
98 |
rational was a better fit.) |
99 |
|
100 |
-- |
101 |
Duncan - List replies preferred. No HTML msgs. |
102 |
"Every nonfree program has a lord, a master -- |
103 |
and if you use the program, he is your master." Richard Stallman |