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

[Thomas Deutschmann]

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