Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model

> These were (and are) not actually the RHEL source releases — rather, they appear to be primarily a testing ground for what might appear in RHEL later

The first part is true, the second is less true and a bit biased in my opinion.

The first part is true because packages can be branched from Stream to the next RHEL minor update at any time, depending on the developers' plans, so it is true that RHEL packages might have never been in CentOS Stream. However: 1) with the exception of embargoed issues, bugs will always be fixed first in Stream and then in RHEL, so you'll never have a situation where Red Hat hides bugfixes from the community 2) the most active packages generally are also the ones that tend to branch last, so for example there will almost always be a kernel in CentOS Stream that is identical to what ends up in a RHEL minor release.

I think it's biased to say that CentOS Stream is a "testing ground for what might appear in RHEL" because Red Hat neither wants nor needs unwilling beta testers. Outside contributions should be code that the community wants in the next RHEL, not reports of bugs that slipped in. Bugs should be fixed upstream and secondarily in Rawhide rather than in CentOS Stream, which aims to be a *preview* of what *will* appear in RHEL later and also a stable, usable rolling distribution in its own right.

> CentOS Stream is a rebuild of RHEL. It is a rebuild of exactly RHEL sources taken from the same git tree as RHEL builds take those sources. It is not a middle - it is RHEL

Almost completely wrong. CentOS Stream is upstream of RHEL and RHEL is periodically branched from CentOS Stream. CentOS Stream is not good is you want your CI to test against a released version of RHEL, because it is always *ahead* of the last RHEL release.

On the other hand CentOS Stream *is* an enterprise Linux distro and it's pretty damn close to RHEL. There will be a CentOS Stream commit for almost any package that is released in RHEL, because the RHEL minor release branches are relatively short-lived and especially no meaningful development happens on them. Compare to the situation until RHEL8 where the sources went internal after the branch from Fedora, and you had years of internal development with nothing but periodic code drops.

> For the 5% of packages, are those the ones at gitlab.com/redhat/centos-stream/src, including a public kernel repo?

No, these "srcgit" repos are turned into regular RPMs; they are the heirs of the internal repos that were used to manage RPMs with thousands of patches applied, the first of which was the kernel. That old tooling dating back to the late 2000s has been cleaned up and is now used in these GitLab repos. See https://docs.centos.org/en-US/stream-contrib/contributing... for more info.

The packages that require manual work for a given minor release are those that: 1) are not available in the UBI (which still has to have public SRPMs); 2) are updated in the first place (many basic packages, say "sed", are not); and 3) are rebased to new upstream releases (if they aren't, all changes are visible in Stream); and 4) had some patches applied after branching from Stream and after stream was rebased.

There is a bigger change which affects packages not in the UBI, one of which is the kernel. This corresponds to just conditions 1 and 2 above, and I also missed it when I first commented here on LWN. After RHEL 9.1 was released, git.centos.org used to receive the same updates as RHEL 9.1 until 9.2 was released, and so on. See for example https://git.centos.org/rpms/kernel/commits/c9. To be honest I have no idea why this was still happening since there was no CentOS Linux 9; but anyway, these stable updates will not be available anymore. In most cases, new tooling will be needed to fetch the updated SRPMs from UBI and that will be it, but for some other packages like the kernel it will be harder and it's possible that the only solution there is clean room reverse engineering or giving up the bug-compatibility to some extent.

More in general, Alma and Rocky have a wide choice of ways they can build their own enterprise-ready Linux distro based on CentOS Stream, just like Facebook does internally. Whether they will stay faithful to their goal of being bug-compatible with RHEL, or perhaps only try to be ABI-compatible, depends on how much effort that want to put in the task; same for how they'll tackle the problem of stable updates They certainly will have to make some tough decisions, and cannot anymore just blindly rebuild whatever Red Hat served them on git.centos.org. ¯⁠\⁠_⁠(⁠ツ⁠)⁠_⁠/⁠¯

Disclaimer: some of the above might not be entirely accurate, but should not be completely wrong either. Corrections are welcome.