[CentOS-devel] Balancing the needs around the CentOS platform

On 12/19/20 9:49 AM, Nico Kadel-Garcia wrote:
> On Sat, Dec 19, 2020 at 12:29 PM Matthew Miller <mattdm at mattdm.org> wrote:
>> It's important to note that the CentOS Linux rebuild never actually had
>> this. RHEL minor releases are actually branches, and you can stay at a minor
>> release and still get security updates. For CentOS Linux, a minor release is
> No. RHEL minor releases are more like source control "tags" than
> branches.


I promise: You do not understand RHEL better than Matthew Miller does.  
Just stop for a moment and listen to him.  You might learn something new.

CentOS point releases are more like source control tags than branches.  
If you have only used CentOS and not RHEL, then I can see why you might 
be confused about this point.  You are accurately describing CentOS.

RHEL, however, branches at point releases.  You can pin an RHEL host to 
a specific point release and continue to get only security and bug 
fixes, and no new features (which are introduced only at point 
releases).  You can't do that with CentOS, because there's only one branch.

The difference is the same as source control.  When you check out a 
branch, you're going to get content not at a specific point in time, but 
all of the latest changes to that branch since it was made.  That's what 
you'll get from RHEL if you install a specific point release, pin it, 
and apply updates.  It's meaningful and supported to have an RHEL 7.5 
host today.  That host can be fully up to date and secure, and still be 
running the 7.5 branch.  When you check out a tag, however, you're 
getting a specific point in time and no change since.  That's what you 
get when you install an old CentOS point release.  CentOS point releases 
don't really have any other meaning.  If you have a host running 
7.5.1804, that just means that you've stopped applying updates, and 
that's not supported by anyone.


>> a point where updates pause for a while while the team scrambles to rebuild
>> a large update of many packages and then those packages all updated in a big
>> chunk _on the single CentOS branch_. So this is always been extra value that
>> Red Hat Enterprise Linux provides that CentOS Linux did not mimic.
> Nothing personal, but "nonsense". See above. The PXE images and
> kernels in the installation media, in particular, mattered. I used to
> publish quite large Red Hat based deployments, and you *never* simply
> ran "yum update" from the live update streams at the time of building
> your new images or testing environments. It's why I published tools
> like my reposync scripts, to generate a lockable internal mirror and
> avoid the streaming update dangers without investing in the very large
> cost of an RHN setup.


You're not making the argument that you intend to make.

RHEL supports pinning hosts to specific point releases in order to 
ensure that they get only bug and security fixes for their lifetime.  
Satellite supports creating views for fully reproducible environments.  
RHEL supports these things out of the box, while CentOS users need to 
roll their own solution.

You just ridiculed Matthew, and then repeated the point that he was 
making, using your own words.