1 |
Hi, everyone. |
2 |
|
3 |
The Council has eventually decided that the proposed agenda item |
4 |
changing the EAPI workflow has not received sufficient public |
5 |
discussion, so I'd like to restart it. |
6 |
|
7 |
|
8 |
The point of contention was a proposed change to the EAPI depreciation |
9 |
workflow. The current workflow consists of roughly three steps: |
10 |
|
11 |
1. The Council decides to deprecate an EAPI. It is added to eapis- |
12 |
deprecated in layout.conf and pkgcheck/repoman start emitting warnings |
13 |
when they're used in ebuilds. This is a 'weak' request for developers |
14 |
to stop using the old EAPI. |
15 |
|
16 |
2. The Council decides to ban an EAPI. This is a pure policy decision |
17 |
with no technical implementation. It is a 'strong' request not to use |
18 |
the old EAPI, and developers have to have a very good reason (e.g. |
19 |
blocked secbump, revbump due to dep changes by a third party and so on) |
20 |
to touch an ebuild and leave it at old EAPI. |
21 |
|
22 |
3. When all ebuilds are removed, the EAPI is added to eapis-banned |
23 |
and the tools now explicitly forbid adding ebuilds with that EAPI. |
24 |
|
25 |
|
26 |
The change proposed in [1] eliminates step 2. The EAPI remains |
27 |
in 'deprecated' policy-state until all ebuilds using it are removed. |
28 |
There is no distinction between 'weak' deprecation ("please don't use |
29 |
it") and 'strong' ban ("you mustn't use it unless you have a very good |
30 |
reason to"). |
31 |
|
32 |
My gut feeling is that having this distinction is useful. However, it |
33 |
has been pointed out that we've probably never really had to use it |
34 |
(i.e. use the "banned" argument to stop someone from using old EAPI) |
35 |
and that the switch from "deprecated" to "banned" state did not really |
36 |
affect porting away from old EAPI. |
37 |
|
38 |
dilfridge's EAPI plots [2] can be helpful in verifying this claim, |
39 |
combined with deprecation and ban dates found on the PMS project page |
40 |
[3]. |
41 |
|
42 |
|
43 |
This decision will also affect another posted agenda item, namely |
44 |
banning EAPI 5. Switching to the new workflow will eliminate that step, |
45 |
and therefore EAPI 5 won't be "banned" until all EAPI 5 ebuilds are |
46 |
removed. |
47 |
|
48 |
WDYT? |
49 |
|
50 |
|
51 |
[1] https://archives.gentoo.org/gentoo-project/message/4a504a0b7aa9199bac3ebcaf54064841 |
52 |
[2] https://www.akhuettel.de/~huettel/plots/eapi.php |
53 |
[3] https://wiki.gentoo.org/wiki/Project:Package_Manager_Specification#Council_approval_and_use_in_Gentoo_repository |
54 |
|
55 |
-- |
56 |
Best regards, |
57 |
Michał Górny |