[gentoo-dev] [RFC] Changes to EAPI ban workflow

[gentoo-dev] [RFC] Changes to EAPI ban workflow

[Michał Górny]

Hi, everyone.

The Council has eventually decided that the proposed agenda item
changing the EAPI workflow has not received sufficient public
discussion, so I'd like to restart it.


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").

My gut feeling is that having this distinction is useful.  However, it
has been pointed out that we've probably never really had to use it
(i.e. use the "banned" argument to stop someone from using old EAPI)
and that the switch from "deprecated" to "banned" state did not really
affect porting away from old EAPI.

dilfridge's EAPI plots [2] can be helpful in verifying this claim,
combined with deprecation and ban dates found on the PMS project page
[3].


This decision will also affect another posted agenda item, namely
banning EAPI 5.  Switching to the new workflow will eliminate that step,
and therefore EAPI 5 won't be "banned" until all EAPI 5 ebuilds are
removed.

WDYT?


[1] https://archives.gentoo.org/gentoo-project/message/4a504a0b7aa9199bac3ebcaf54064841
[2] https://www.akhuettel.de/~huettel/plots/eapi.php
[3] https://wiki.gentoo.org/wiki/Project:Package_Manager_Specification#Council_approval_and_use_in_Gentoo_repository

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow

[Francesco Riosa]

[-- Attachment #1: Type: text/plain, Size: 604 bytes --]

Il giorno dom 11 lug 2021 alle ore 22:55 Michał Górny <mgorny@gentoo.org>
ha scritto:
[snip]

>
> This decision will also affect another posted agenda item, namely
> banning EAPI 5.  Switching to the new workflow will eliminate that step,
> and therefore EAPI 5 won't be "banned" until all EAPI 5 ebuilds are
> removed.
>
> If this means that stable EAPI 5 only packages will continue to work - at
least until someone will replace them with a better EAPI stable version
then you have my complete moral support.
This obviously also affect all eclasses used by EAPI 5 only stable packages.

[-- Attachment #2: Type: text/html, Size: 982 bytes --]

Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow

[Aaron Bauman]

[-- Attachment #1: Type: text/plain, Size: 1179 bytes --]

On Sun, Jul 11, 2021 at 10:54:45PM +0200, Michał Górny wrote:
> Hi, everyone.
> 
> The Council has eventually decided that the proposed agenda item
> changing the EAPI workflow has not received sufficient public
> discussion, so I'd like to restart it.
> 
> 
> 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").
> 

There seems to be a lot of time spent on whether to take 1 minute
to officialy ban an EAPI in a meeting. Plots are cool, but nothing
statistically significant is going to show given the small issues we had
in the past. The formality is simply to keep those small issues from
being a headache to other devs.

Just officially ban it, send out a message, and use the best judgement
when enforcing it (should it even need to be enforced).

-Aaron

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow

[Marek Szuba]

[-- Attachment #1.1: Type: text/plain, Size: 1310 bytes --]

On 2021-07-11 21:54, Michał Górny wrote:

> My gut feeling is that having this distinction is useful.  However, it
> has been pointed out that we've probably never really had to use it
> (i.e. use the "banned" argument to stop someone from using old EAPI)
> and that the switch from "deprecated" to "banned" state did not really
> affect porting away from old EAPI.

For the benefit of those not interested in sifting through the logs of 
Council meetings, here is a quick reiteration of my take on this:

1. Maybe it's my professional bend speaking but it feels to me like we 
really should establish a clear, GLEP-documented EAPI life cycle with 
well-defined meaning of individual stages. I will work on preparing a 
suitable proposal;

2. Until the above has introduced a (hopefully) better system, I am all 
for removing step 2 because it makes the procedure less bureaucratic.


On 2021-07-12 02:11, Aaron Bauman wrote:

 > Just officially ban it, send out a message, and use the best judgement
 > when enforcing it (should it even need to be enforced).

And the point of establishing a policy doomed from start to be enforced 
weakly or not at all is? Other than making the Council look like we care 
more about theatrics than actual governance, that is.

-- 
Marecki


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow

[Aaron Bauman]

[-- Attachment #1: Type: text/plain, Size: 1648 bytes --]

On Mon, Jul 12, 2021 at 11:38:18AM +0100, Marek Szuba wrote:
> On 2021-07-11 21:54, Michał Górny wrote:
> 
> > My gut feeling is that having this distinction is useful.  However, it
> > has been pointed out that we've probably never really had to use it
> > (i.e. use the "banned" argument to stop someone from using old EAPI)
> > and that the switch from "deprecated" to "banned" state did not really
> > affect porting away from old EAPI.
> 
> For the benefit of those not interested in sifting through the logs of
> Council meetings, here is a quick reiteration of my take on this:
> 
> 1. Maybe it's my professional bend speaking but it feels to me like we
> really should establish a clear, GLEP-documented EAPI life cycle with
> well-defined meaning of individual stages. I will work on preparing a
> suitable proposal;
> 
> 2. Until the above has introduced a (hopefully) better system, I am all for
> removing step 2 because it makes the procedure less bureaucratic.
> 
> 
> On 2021-07-12 02:11, Aaron Bauman wrote:
> 
> > Just officially ban it, send out a message, and use the best judgement
> > when enforcing it (should it even need to be enforced).
> 
> And the point of establishing a policy doomed from start to be enforced
> weakly or not at all is? Other than making the Council look like we care
> more about theatrics than actual governance, that is.
> 
> -- 
> Marecki
> 

It is not theatrics. It is a policy that was effective in the past and
is used in lieu of a technical measure. Albeit, it is unlikely to be
enforced because most people abide by the deprecation warnings.

-Aaron


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow

[Michał Górny]

On Mon, 2021-07-12 at 09:33 -0400, Aaron Bauman wrote:
> On Mon, Jul 12, 2021 at 11:38:18AM +0100, Marek Szuba wrote:
> > On 2021-07-11 21:54, Michał Górny wrote:
> > 
> > > My gut feeling is that having this distinction is useful.  However, it
> > > has been pointed out that we've probably never really had to use it
> > > (i.e. use the "banned" argument to stop someone from using old EAPI)
> > > and that the switch from "deprecated" to "banned" state did not really
> > > affect porting away from old EAPI.
> > 
> > For the benefit of those not interested in sifting through the logs of
> > Council meetings, here is a quick reiteration of my take on this:
> > 
> > 1. Maybe it's my professional bend speaking but it feels to me like we
> > really should establish a clear, GLEP-documented EAPI life cycle with
> > well-defined meaning of individual stages. I will work on preparing a
> > suitable proposal;
> > 
> > 2. Until the above has introduced a (hopefully) better system, I am all for
> > removing step 2 because it makes the procedure less bureaucratic.
> > 
> > 
> > On 2021-07-12 02:11, Aaron Bauman wrote:
> > 
> > > Just officially ban it, send out a message, and use the best judgement
> > > when enforcing it (should it even need to be enforced).
> > 
> > And the point of establishing a policy doomed from start to be enforced
> > weakly or not at all is? Other than making the Council look like we care
> > more about theatrics than actual governance, that is.
> > 
> > -- 
> > Marecki
> > 
> 
> It is not theatrics. It is a policy that was effective in the past and
> is used in lieu of a technical measure. Albeit, it is unlikely to be
> enforced because most people abide by the deprecation warnings.
> 

That's the whole point.  Do we need a two-step deprecation/ban if 'most'
people abide by deprecation warnings?

I'm wondering if the two-step deprecation/ban isn't a symptom of a wider
problem.  After all, we want people to stop using old EAPIs after
they're deprecated, not after they're explicitly forbidden to use them.

Maybe the whole point is that we should stop trying to draw explicit
lines everywhere and instead assume -- per common sense -- that
deprecating is enough for people to eventually stop using them.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow

[Aaron Bauman]

[-- Attachment #1: Type: text/plain, Size: 2521 bytes --]

On Mon, Jul 12, 2021 at 04:59:06PM +0200, Michał Górny wrote:
> On Mon, 2021-07-12 at 09:33 -0400, Aaron Bauman wrote:
> > On Mon, Jul 12, 2021 at 11:38:18AM +0100, Marek Szuba wrote:
> > > On 2021-07-11 21:54, Michał Górny wrote:
> > > 
> > > > My gut feeling is that having this distinction is useful.  However, it
> > > > has been pointed out that we've probably never really had to use it
> > > > (i.e. use the "banned" argument to stop someone from using old EAPI)
> > > > and that the switch from "deprecated" to "banned" state did not really
> > > > affect porting away from old EAPI.
> > > 
> > > For the benefit of those not interested in sifting through the logs of
> > > Council meetings, here is a quick reiteration of my take on this:
> > > 
> > > 1. Maybe it's my professional bend speaking but it feels to me like we
> > > really should establish a clear, GLEP-documented EAPI life cycle with
> > > well-defined meaning of individual stages. I will work on preparing a
> > > suitable proposal;
> > > 
> > > 2. Until the above has introduced a (hopefully) better system, I am all for
> > > removing step 2 because it makes the procedure less bureaucratic.
> > > 
> > > 
> > > On 2021-07-12 02:11, Aaron Bauman wrote:
> > > 
> > > > Just officially ban it, send out a message, and use the best judgement
> > > > when enforcing it (should it even need to be enforced).
> > > 
> > > And the point of establishing a policy doomed from start to be enforced
> > > weakly or not at all is? Other than making the Council look like we care
> > > more about theatrics than actual governance, that is.
> > > 
> > > -- 
> > > Marecki
> > > 
> > 
> > It is not theatrics. It is a policy that was effective in the past and
> > is used in lieu of a technical measure. Albeit, it is unlikely to be
> > enforced because most people abide by the deprecation warnings.
> > 
> 
> That's the whole point.  Do we need a two-step deprecation/ban if 'most'
> people abide by deprecation warnings?
> 
> I'm wondering if the two-step deprecation/ban isn't a symptom of a wider
> problem.  After all, we want people to stop using old EAPIs after
> they're deprecated, not after they're explicitly forbidden to use them.
> 
> Maybe the whole point is that we should stop trying to draw explicit
> lines everywhere and instead assume -- per common sense -- that
> deprecating is enough for people to eventually stop using them.
> 

As said, in lieu of that we have a fail safe.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 2846 bytes --]

Hi,

it's not clear to me what will be the consequences of this change.

I am expecting good faith and that nobody will add an ebuild with 
deprecated EAPI just for fun or because maintainer prefers retro stuff.

So looking at the reasons to bump without touching EAPI:

a) Because of a changing dep/add slot operator

b) Because of a security vulnerability.

c) Other critical fixes which should reach users ASAP.

In addition, all of this could happen by non-primary maintainer of the 
package.

In case such a change would force anyone who is touching the ebuild to 
also fix the ebuild itself and migrate to latest EAPI -- even 
non-primary maintainers -- this would be far away from any reality and 
would cause pain for users in the end because people wouldn't touch 
these packages anymore.

Keep in mind: Even if you are the primary maintainer, if you have 
foo-1.2.3 (stable for a while but using deprecated EAPI) and upstream 
just released foo-2.0 (a complete rewrite after 10 years, not yet ready 
for stabilization but added with latest EAPI) and you would now need to 
fix something critical in v1.2.3, this would be impossible because 
adding a patch/change deps is one thing, making an EAPI change _will_ 
require more testing which will prevent fast stabilization (remember 
when trailing slash behavior changed when we had no QA/CI checks able to 
catch most (still not all!) problems caused by incomplete EAPI bumps 
which had real impact when those ebuilds were merged to disk).

If the above will be still allowed (and I believe it *must* be still 
allowed), we cannot get rid of step 2 -- we will need exemptions.

I would really like to understand why people in Gentoo believe we should 
eliminate step 2 and also start enforcing policy.

I agree with the latter: If we create a rule which isn't enforceable, 
it's not a rule and we shouldn't create it as such. But in this case, 
like said, I believe we need the exemptions, which makes it impossible 
to enforce something, so we cannot create a (new) policy in first place.

But is it really a problem? Is such a new policy really needed? Are 
people really pushing lots of ebuilds with EAPIs we already marked as 
deprecated? If it is a real problem, do we actually have information why 
maintainers are doing that? Trying to understand why someone keeps using 
deprecated EAPI could help more like a policy which is more likely to 
cause more stale packages/ignored bugs assuming these maintainer didn't 
do that for fun or wilful ignorance. At the moment, the whole idea of 
creating a policy for that problem sounds like shooting sparrows with 
cannons. But maybe I am missing something...


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow

[Aaron Bauman]

[-- Attachment #1: Type: text/plain, Size: 1043 bytes --]

On Mon, Jul 12, 2021 at 04:21:02PM +0200, Thomas Deutschmann wrote:
> Hi,
> 
> it's not clear to me what will be the consequences of this change.
> 
> I am expecting good faith and that nobody will add an ebuild with deprecated
> EAPI just for fun or because maintainer prefers retro stuff.
> 
> So looking at the reasons to bump without touching EAPI:
> 
> a) Because of a changing dep/add slot operator
> 
> b) Because of a security vulnerability.
> 
> c) Other critical fixes which should reach users ASAP.
> 
> In addition, all of this could happen by non-primary maintainer of the
> package.
> 

Like a lot of policies and rules in Gentoo there are exceptions. This is
why we have various projects and teams that enforce said policies and
rules. Finally, we have escalation procedures with various independent
bodies to handle it should common sense prove to be an uncommon virtue.

We cannot legislate common sense.

So many people spending so much time to arrive at an imperfect policy, as
usual.

-Aaron

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow

[Joonas Niilola]

[-- Attachment #1.1: Type: text/plain, Size: 1602 bytes --]

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]