epel/steering

EPEL minor version retirement timing #366

New issue

Closed

opened 2026-05-29 20:45:18 +00:00 by carlwgeorge · 4 comments

carlwgeorge commented

2026-05-29 20:45:18 +00:00

Owner

This is the current EPEL EOL policy for minor versions:

For EPEL releases with minor versions (e.g. EPEL 10) the process is similar. When a new RHEL minor version is released, the branch associated to the previous minor release goes end-of-life. This means that it should go through the same retirement process. The final minor release will be active until the end of overall EPEL major release.

In Fedora, if you try to submit an update through the bodhi web interface within 30 days of that release's EOL date, it will display a warning with the upcoming EOL date. A few people have asked if we can do something similar for EPEL minor versions. However, EPEL minor EOL dates are determined by the RHEL schedule, which isn't public information.

I submitted a bodhi RFE to ask for ways to display that warning without setting an EOL date. It was suggested to instead delay the EPEL minor EOL some amount of time after the new RHEL minor version release. That would utilize the existing mechanism and would just be a policy change. Process wise that would mean setting the EOL date for an EPEL minor once the next RHEL minor is released, e.g setting it for one week later. Any updates submitted before that would have time to move to stable within the default "stable by time" threshold of 7 days. Any updates submitted after that would get the warning, could still be submitted, but would need to get karma to get promoted faster than the time threshold.

Should we change the policy from immediate EOL when the next RHEL minor is released, or delay it for a week or two to have a period of time where packagers are warned that the EOL is coming?

This is the current [EPEL EOL policy for minor versions](https://docs.fedoraproject.org/en-US/epel/epel-policy/#policy_for_end_of_life_releases): > For EPEL releases with minor versions (e.g. EPEL 10) the process is similar. When a new RHEL minor version is released, the branch associated to the previous minor release goes end-of-life. This means that it should go through the same retirement process. The final minor release will be active until the end of overall EPEL major release. In Fedora, if you try to submit an update through the bodhi web interface [within 30 days of that release's EOL date](https://github.com/fedora-infra/bodhi), it will display a warning with the upcoming EOL date. A few people have asked if we can do something similar for EPEL minor versions. However, EPEL minor EOL dates are determined by the RHEL schedule, which isn't public information. I submitted a [bodhi RFE](https://github.com/fedora-infra/bodhi/issues/5988) to ask for ways to display that warning without setting an EOL date. It was suggested to instead delay the EPEL minor EOL some amount of time after the new RHEL minor version release. That would utilize the existing mechanism and would just be a policy change. Process wise that would mean setting the EOL date for an EPEL minor once the next RHEL minor is released, e.g setting it for one week later. Any updates submitted before that would have time to move to stable within the default "stable by time" threshold of 7 days. Any updates submitted after that would get the warning, could still be submitted, but would need to get karma to get promoted faster than the time threshold. Should we change the policy from immediate EOL when the next RHEL minor is released, or delay it for a week or two to have a period of time where packagers are warned that the EOL is coming?

carlwgeorge added the

meeting

label

2026-05-29 20:45:18 +00:00

kevin commented

2026-05-30 16:19:29 +00:00

Contributor

I don't think the delay is worthwhile.
It might be nice to just have a generic header on epel updates (against X.Y branches) saying "This is a minor branch and will go EOL when the RHEL release it's using goes EOL" and perhaps point them to something that mentions general timeframes or something.

I don't think the delay is worthwhile. It might be nice to just have a generic header on epel updates (against X.Y branches) saying "This is a minor branch and will go EOL when the RHEL release it's using goes EOL" and perhaps point them to something that mentions general timeframes or something.

rcallicotte commented

2026-06-05 23:54:04 +00:00

Member

Maybe publishing a warning that EOL for x.y branches is "expected_within this month" would be sufficient warning? Package maintainers generally know when the new RHEL versions are due to release based upon past releases. I agree with @kevin, the delay is not worthwhile.

Maybe publishing a warning that EOL for x.y branches is "_expected_within this month_" would be sufficient warning? Package maintainers generally know when the new RHEL versions are due to release based upon past releases. I agree with @kevin, the delay is not worthwhile.

carlwgeorge commented

2026-06-06 03:54:27 +00:00

Author

Owner

FWIW there is a warning email that is sent to the epel-devel mailing list. Here is the last one:

https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/MDNX65FWS272L23MQCVHEFEZWZAQQVYC/

Currently our SOP suggests sending that at the beginning of the month where the EOL is expected to happen.

https://docs.fedoraproject.org/en-US/infra/release_guide/sop_epel_minor_eol/#_send_announcement

This issue is specifically about getting a warning displayed in bodhi so maintainers see it while submitting an update for a near-EOL minor release. I'm not opposed to just saying the email warning is good enough and not making a change to the SOP.

FWIW there is a warning email that is sent to the epel-devel mailing list. Here is the last one: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/MDNX65FWS272L23MQCVHEFEZWZAQQVYC/ Currently our SOP suggests sending that at the beginning of the month where the EOL is expected to happen. https://docs.fedoraproject.org/en-US/infra/release_guide/sop_epel_minor_eol/#_send_announcement This issue is specifically about getting a warning displayed in bodhi so maintainers see it while submitting an update for a near-EOL minor release. I'm not opposed to just saying the email warning is good enough and not making a change to the SOP.

tdawson commented

2026-06-10 18:19:14 +00:00

Owner

This has been discussed in the EPEL Steering Committee meeting for the past two weeks. In the end it was decided to continue as we have.
We are not against re-opening this at a later date.

This has been discussed in the EPEL Steering Committee meeting for the past two weeks. In the end it was decided to continue as we have. We are not against re-opening this at a later date.