When CentOS Linux 8 went EOL this also had impacts on the SIGs. Most SIGs transitioned from building against CentOS Linux 8 to CentOS Stream 8. Later community members asked to allow SIGs to build against RHEL 1. This has been implemented and SIGs have been allowed to optionally build against RHEL 8 2. However, this has all only been implemented for EL 8, and even there some parts are still missing or not in a desirable state, see 3 about SIG release pkg state. Recently a similar discussion started about providing RHEL 9 buildroots 4.
There are some open questions which can afaik only been answered by the CentOS Board. I will skip arguing why it is reasonable to allow SIGs to build against RHEL, in addition to CentOS Stream, as it seems that everyone involved already agrees on that point.
Open questions:
For how long will a certain RHEL major release buildroots be supported in CBS? For CentOS Stream buildroots this is determined by their EOL, but for RHEL I ask for clarification for how long SIGs can assume that buildroots are available in CBS. Reasonable options seem to be till the end of “Full Support” or “Maintenance Support” of the RHEL life cycle. I personally prefer till the end of "Maintenance Support".
Will SIGs be allowed to produce centos-release* pkgs for RHEL? If yes, will these be stored in a extras$MAJOR-extras-common tag similar to how it is done for Stream 8 and 9. This would allow RHEL users to easily consume SIG content. Probably even provide a "centos-release-extras" (name only serves as a placeholder) including the CentOS-SIG-Extras GPG key and repository config pointing to content release in extras$MAJOR-extras-common tag. Also see 3, first post last paragraph.
IMHO it makes most sense to push SIG packages built for RHEL 9 to mirror.stream.centos.org/SIGs/9/$SIG, especially having in mind that most content stored on mirror.centos.org will be EOL in 2024: CentOS Linux 7, June 30th, 2024 and CentOS Stream 8, May 31st, 2024.
Maybe some of these questions are only technical and do not even concern the CentOS Board. Comments in 3 and 4 indicate that at least some decisions by the Board are required.
I have added this to the agenda for the August 10th Board meeting
Pat took this as an action item during the meeting. It was requested we create a clear and specific statement of desired functionality within RHEL build root on CBS and sync up with EPEL lifecycle if possible
Requested RHEL Buildroots for CentOS Community Build System (and Special Interest Groups):
Based on the discussion at the August CentOS Board meeting, I’d like to propose the following:
CBS, and by extension SIGs, should have access to RHEL build roots for the entire “Full Support” and “Maintenance Support” cycle of RHEL. Additionally, after conversations with the folks at Fedora EPEL, we would like to keep the RHEL build roots active for 30 days after the end of “Maintenance Support” to allow builders to finalize their content for the end of the traditional (10 year) lifecycle for the specific RHEL version.
What this means in practice – an example with RHEL8 and the CentOS Kmod SIG:
RHEL 8 reaches end of Maintenance Support on May 31, 2029. Prior to this date, the CBS RHEL 8 build roots should continue to track the published RHEL 8 content – receiving updates as they arrive in RHEL 8. From June 1, 2029 until June 30, 2029, the RHEL 8 build roots should continue to be available as build targets on CBS. However, the RHEL 8 content in those build roots is expected not to change – it should remain matching the final production repo published for RHEL8. This deliberately and explicitly excludes content coming from any Extended Update Support subscriptions.
If, for example, a RHEL8 kernel is published May 21, 2029. The CentOS Kmod SIG may want to update their kernel modules to match any changed symbols. This may take a week or two for the module source to be patched for any changed symbols. The patching of the module source may introduce some bugs or other issues user might report. Leaving the build roots active for 30 days will allow time for end users to submit bug reports and for the maintainers to evaluate approaches to address them – including the possibility of not addressing the issues due to lifecycle constraints. Complex packages may take a while to patch and to resolve critical regressions. Since it is possible to for new updates to land in RHEL8 on May 31, 2029, it is important to leave our SIGs some time to react to those updates if they desire.
This would permit content to be built against RHEL 8 after May 31, 2029 and published by CBS for 30 days. The exact destination of the new content (vault.centos.org or mirrors.centos.org) is not specified here – provided the updated SIG content is not lost. The intent here is not to extend the life of RHEL8, but rather to provide a clear timetable for SIGs to finalize their RHEL8 content. The intent is as follows: When RHEL8 is no longer receiving normal updates, CentOS SIG content should be available from an archival source and work as that SIG expects. The 30 day window provides a clear timetable for SIGs to evaluate how they would like to respond to any late lifecycle updates and make any changes they desire after RHEL8 is finalized.
This explicitly does not commit the SIGs to work on any content produced at the tail end of Maintenance Support which would run past the end date. Instead, this should be viewed as a way for SIGs to decide for themselves how they want to react to this content. A 30 day window provides enough time to produce some final updates, if the SIG feels their work would benefit from finalization. This window is deliberately short as to promote the concept of finishing any outstanding issues rather than a continuation of support.
I spoke with the EPEL folks (Troy and Carl) and they do not have a formalized/published policy for the end of EPEL build targets/publication. In practice it is aimed for shortly after the end of Maintenance Support. A 30 day cycle would line up nicely with this concept but provide formalization.
From the Kmods SIG perspective the proposal by @jcpunk sounds good. The 30 day window gives enough time to fix any issues caused by late RHEL updates.
Should providing this 30 day window be an issue we are fine with RHEL buildroots being unavailable in CBS immediately after RHEL reaches the end of Maintenance Support. This might lead to SIGs not being able to fully support the latest RHEL compose before the end of Maintenance Support. But at that time people are relying on unsupported software anyway.
Metadata Update from @jcpunk: - Issue assigned to jcpunk
Opened https://pagure.io/centos-infra/issue/1002 to track the work on the Infra side.
Is anything further needed here?
From my side it is all good. @jcpunk Your summary above is sufficient for me so that we can expect to be able to support our packages until EOL (end of maintenance support) of RHEL. According to the centos-infra issue 1002 there is also no issue with allowing SIGs to built for RHEL as described in your summary from Infra perspective. We "just" have to sort out the technical details. I'll start a discuss about that on centos-devel.
Summary: Assuming no one else has something which needs to be done, the issue can be closed. Thanks!
:) Sounds good!
Metadata Update from @jcpunk: - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.