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: OpenPGP_signature
Description: OpenPGP digital signature

Reply via email to