Mailing List Archive

[RFC] Changes to EAPI ban workflow
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: [RFC] Changes to EAPI ban workflow [ In reply to ]
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.
Re: [RFC] Changes to EAPI ban workflow [ In reply to ]
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
Re: [RFC] Changes to EAPI ban workflow [ In reply to ]
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
Re: [RFC] Changes to EAPI ban workflow [ In reply to ]
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
Re: [RFC] Changes to EAPI ban workflow [ In reply to ]
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
Re: [RFC] Changes to EAPI ban workflow [ In reply to ]
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
Re: [RFC] Changes to EAPI ban workflow [ In reply to ]
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: [RFC] Changes to EAPI ban workflow [ In reply to ]
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.
Re: [RFC] Changes to EAPI ban workflow [ In reply to ]
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