If I were Rocky, Alma, Oracle and/or SUSE, I'd be collaborating to define our own point-release schedule off CentOS Stream*, and trying to make our blessèd commits usurp Red Hat's as industry standard.

* with blackjack! and public git repos!

SUSE might do that.

Rocky, Alma, and Oracle cannot do that because they are never going to write the documentation, do the testing, or provide the certifications that make a RHEL release a RHEL release.

The point releases of a RHEL fork are meaningless unless they are identical to RHEL. If you cannot get real RHEL, your better off with CentOS Stream than an incompatible point release.

> they are never going to write the documentation, do the testing, or provide the certifications that make a RHEL release a RHEL release.

That's precisely what I'm suggesting they attempt.

> The point releases of a RHEL fork are meaningless unless they are identical to RHEL.

Why? (I'm not trying to be belligerent here — I genuinely don't understand why.)

> If you cannot get real RHEL, your better off with CentOS Stream than an incompatible point release.

I thought CentOS Stream essentially is an incompatible point-release — or rather, RHEL is a point-release off CentOS Stream's rolling release.

Does Red Hat provide that much worse documentation for CentOS Stream than for RHEL?

I guess I just don't understand what is the “secret sauce” that makes CentOS Stream so useless, but RHEL so compelling (or even a rebranded-but-otherwise-identical rebuild of RHEL like CentOS 7).

CentOS Stream and RHEL diverge. (a) many bug fixes are back ported to RHEL 9.x, but not to the Stream 9 at the same time (b) they fix bugs right away on RHEL 9.x, but delay them for a long time (c) some packages in the Stream are from the latest upstream, and many major versions ahead of the same in RHEL 9.x