EPEL 10 retirement policy

Project Discussion
1

Because EPEL 10 has introduced minor version branches, I think it’s time to re-evaluate the EPEL package retirement policy.

The current policy allows for maintainers to retire a package at any point during the lifecycle of an EPEL version (either immediately or with a two week warning announcement). This policy was designed to accommodate the various reasons for retiring an EPEL package during the entire lifecycle of a major version only branch. I think having minor version branches gives us the opportunity to be more granular with this policy.

I propose that we allow retiring a package at any point on the leading branch (e.g. epel10), but not allow retiring a package in trailing branches (e.g. epel10.0).

For CentOS users, EPEL package retirements will work the exact same way they do now. For RHEL users, EPEL packages will not be removed during the lifecycle of a minor version, but may be removed when upgrading to a new minor version. This would make package retirements a bit more predictable.

Thoughts?

2 Likes
2

This seems reasonable to me. Do you plan to block this in tooling, or just have it as a standing policy? If we plan to block it, we might want a carveout for packages that weren’t supposed to be branched in the first place (e.g. the m1n1 case that I retired in epel10.0 yesterday after our discussion).

3

Great question. Currently the koji hub policy allows blocking packages in both the epel10.0 and epel10.1 tags. I would want to change that to allow the blocking in the epel10.1 tag, but not in the epel10.0 tag, and then adjust those as we go forward.

I think the m1n1 situation will be a pretty rare thing that a koji admin can handle as a one-off.