On 11.7.2021 23.54, Michał Górny wrote:
> Hi, everyone.
>
>
>
> The point of contention was a proposed change to the EAPI depreciation
> workflow. The current workflow consists of roughly three steps:
>
> 1. The Council decides to deprecate an EAPI. It is added to eapis-
> deprecated in layout.conf and pkgcheck/repoman start emitting warnings
> when they're used in ebuilds. This is a 'weak' request for developers
> to stop using the old EAPI.
>
> 2. The Council decides to ban an EAPI. This is a pure policy decision
> with no technical implementation. It is a 'strong' request not to use
> the old EAPI, and developers have to have a very good reason (e.g.
> blocked secbump, revbump due to dep changes by a third party and so on)
> to touch an ebuild and leave it at old EAPI.
>
> 3. When all ebuilds are removed, the EAPI is added to eapis-banned
> and the tools now explicitly forbid adding ebuilds with that EAPI.
>
>
> The change proposed in [1] eliminates step 2. The EAPI remains
> in 'deprecated' policy-state until all ebuilds using it are removed.
> There is no distinction between 'weak' deprecation ("please don't use
> it") and 'strong' ban ("you mustn't use it unless you have a very good
> reason to").
> So it's about removing a bureaucratic step that never resulted in anything before? Sounds good. The 2nd step should be considered being added back IF people kept deliberately adding deprecated EAPI ebuilds. But as you said, guess it's not a problem with active maintainers and current available QA tools. -- juippis
OpenPGP_signature
Description: OpenPGP digital signature
