@bsherman (re: @barry @m2Giles ) - to add another perspective, when I read your original post I read “churn” with my PM hat on … namely project $'s. How much compute and storage cost is it involving to generate bootc images (and ISOs) and deliver them to users.
That is how I interpreted “churn”. FYI.
Here’s the thing, I have measured this scientifically, so speculative unscientific anecdotes are not really interesting to me. Those tend to follow along with whatever outcome people are hoping for, rather than following the data.
And if you measured a CentOS Stream 9 system for a similar duration shifted six months earlier, you would see a similar number of package updates. Like I said before, the difference is if you’re getting those updates spaced out over six months, or mostly in a large minor version update.
Including third party repos in your data invalidates it. EPEL publishes updates nightly, so depending on which EPEL packages you have installed and the corresponding maintainer activity, that alone will completely skew the numbers. I don’t know how often Nvidia updates their packages, but it definitely adds additional variability to the data. Just summarizing this as “2x churn” is insufficient.
That not typically how things work. In most cases, the software version stays the same, an update is made that adds a backported bug fix patch, then no other changes happen and the same update is released in RHEL. So it looks more like this:
When the software version does actually change, it’s likely to also be passed through from CentOS to RHEL without additional iterations, like so:
Furthermore, it’s also possible for RHEL to have more churn (as in more literal number of updates) than the CentOS package. A RHEL package can have multiple independent updates with backported fixes, and then update to a rebased version, when the CentOS package just goes straight for the rebase.
The workflow you described can happen also, but is less common than the ones I just described. In all of these cases, these updates fit within the scope of the ACG, so they are RHEL-style compatible updates, not really disruptive churn (especially in the context of an image based approach).
You misunderstand the origin of the name Stream. In RHEL development, there are multiple branches RHEL maintainers work in. Work on major version branches is known as “y-stream” work, and work on minor version branches is know as “z-stream” work. When a maintainer needs to make a fix, it’s common for them to be working across multiple y-streams and z-streams. When we moved CentOS upstream of RHEL, it took the place of the y-stream, thus leading to the concept of it being the “CentOS-stream” of RHEL, and thus the eventual name of CentOS Stream. Discounting it because it’s a “stream” of updates is silly because RHEL is also a “stream” of updates.
Only if 1.3.1 is planned for the next minor version of RHEL. It’s not something you can assume. Most RHEL packages never get rebased to a new version, and even the ones that do get rebased go through a careful process to evaluate if each rebase is appropriate.
For background, I used to be on the CentOS team and built and released CentOS Linux 8 and CentOS Stream 8. Most of the updates involved us building it for CS8, releasing it in CS8, and then releasing the same build in CL8 4-6 months later. It doesn’t make any sense to claim that this makes it unsuitable as a server OS. Now I’m on the EPEL team, and we’ve redesigned EPEL 10 to prioritize CentOS, and most EPEL 10 updates are built against CentOS, proving out it’s viability as a solid platform to build against.
This isn’t how I meant it, but your point well complements my perspective. In addition to rapid kernel change, rapid changes upstream can result in more images built, plus more maintenance in handling those changes.
Cayo? I like the name!