Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow
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
Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow
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. signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow
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
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 signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow
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 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow
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 signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow
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 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow
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
signature.asc
Description: PGP signature
Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow
Il giorno dom 11 lug 2021 alle ore 22:55 Michał Górny 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.
[gentoo-dev] [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
