Just to recap the latest in the #Redhat RHEL vs downstreams not offering them any value drama:

Redhat publically states that downstream rebuilders offer them no value, and the RHEL community should all be working in the Centos-stream sandbox, because that's where the community is, because it has community right there in the name, and that's where the code fixes can land, and community is only about lines of code in the repo.

@almalinux goes "alright, no value in us being a 1:1 rebuild of RHEL, then we're cutting our own path while being based on Centos-stream, staying ABI compatible with RHEL, but we'll fix our own bugs when we find them"

Alma Linux then finds a CVE in the iperf3 server impacting everyone in the Enterprise Linux 9 ecosystem, so they release the fix for AlmaLinux, and then immediately open pull requests for Fedora and Centos-stream to land the fix upstream. Which would seem to be exactly what Redhat was asking for this whole time.

Redhat's response to the centos-stream pull request? "There is no current customer demand for this fix in RHEL, so we're not interested in this fix"

The astute will notice that the pull request is feeding into centos-stream, and not RHEL. But they're making merge decisions here based on immediate customer demand in RHEL.

So maybe this whole "Centos-stream is the community distro" line was bullshit and it really is just the beta testing ground for RHEL, just like all of us kind of thought it was while getting shouted down by the centos-stream advocates this whole time.

So Redhat is still doing great.

https://gitlab.com/redhat/centos-stream/rpms/iperf3/-/merge_requests/5

Fixes CVE-2023-38403 - Resolves: rhbz#2223729 (!5) · Merge requests · Red Hat / centos-stream / rpms / iperf3 · GitLab

Summary of Changes Fixes CVE-2023-38403 Approved Development Ticket

GitLab

Is Redhat obligated to accept this pull request just because it's coming from a downstream contributor? No.

Does it always make sense to pull a minor fix into RHEL and risk the possibility of side effects? No.

Should Redhat engineers be pulling in fixes which they fully know won't be pulled into RHEL? Eh.

Does Redhat declining the very first notable contribution to Centos-stream after going scorched earth telling people to contribute to cento-stream have a bad look to it?

Yeah, this is the problem.

@kwf On the third point, it's also no. Things are only merged into CentOS Stream if they are planned for the next minor version of the corresponding RHEL major version. Merging things that aren't intended for RHEL would be against what we've described CS as. It's not a sandbox to throw out new features/fixes to see if they work. It's the staging area for QA-tested, RHEL-compatible updates that are approved for the next minor version.
@carlwgeorge honestly, calling it "OpenRHEL" would have been so much less confusing than centos-stream.
@kwf @carlwgeorge Well, no. Because RedHats Premium Product (tm) OpenShift is also not the upstream project.
@ttk @carlwgeorge and Centos was a 10 year support distro. No name is perfect. 🤷
@kwf @carlwgeorge yeah, i only wanted to emphasise that the "open" prefix in redhat context is already burnt somehow