Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] [RFC] Changes to EAPI ban workflow
Date: Sun, 11 Jul 2021 20:54:54
Message-Id: f94ca0143afadeddf73d8e7990943a1b89c83264.camel@gentoo.org
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

Replies

Subject Author
Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow Francesco Riosa <vivo75@×××××.com>
Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow Aaron Bauman <bman@g.o>
Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow Marek Szuba <marecki@g.o>
Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow Thomas Deutschmann <whissi@g.o>
Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow Joonas Niilola <juippis@g.o>