On Thu, Jan 15, 2026 at 5:15 AM Florian Weimer fweimer@redhat.com wrote:
- Neal Gompa:
On Thu, Jan 15, 2026 at 3:02 AM Florian Weimer via devel devel@lists.centos.org wrote:
- Amy Marrich via devel:
Deliverables
- SIG Repositories: builds of the kernel, qemu-kvm, and libvirt containing the latest upstream-bound patches.
Would it be possible to make it a SIG requirement to reach out to relevant RHEL Product Owners before the scope is extended to additional components?
Please no. That turns the relationship upside down and invalidates the idea that CentOS is supposed to be a community upstream venue.
This is just a way to avoid duplicate work and that the development activity occurs in the right place.
There are no public CentOS Stream developer meetings or similar resources for most components, otherwise I would have suggested to engage with those.
The reason those don't exist is not because we don't want them, but because RHEL developers need to be present in the CentOS space to make that work. We've had a facility for a while now to organize such meetings, but it's not particularly useful if we don't have them.
Even without meetings, CentOS has a public Matrix room that pretty much all the SIG people are in: https://matrix.to/#/#centos-devel:fedoraproject.org
We probably don't need the overhead of meetings if there was a general expectation that people from the RHEL side were present in that room and here on the mailing list to discuss things (similar to how it works in Fedora).
As an example, CentOS Hyperscale has in the past and will in the future built virtualization components, and we build kernels today. There's no way we'd block that on talking to RHEL POs that we don't even know to do that work.
It's a different SIG, with different goals.
My understanding is that the Nvidia enablement SIG wants to merge most things back into CentOS Stream eventually. The SIG needs to coordinate with CentOS Stream development to some extent, otherwise that's not going to happen.
That's not very different from Automotive, Virtualization, Proposed Updates, or even Hyperscale to some extent. Our ability to do this is dependent on RHEL folks being in the spaces where we are so that this can be done. Those folks should be *here* not the other way around.
-- 真実はいつも一つ！/ Always, there's only one truth!