[CentOS-devel] Before You Get Mad About The CentOS Stream Change, Think About…

On Wed, Dec 23, 2020 at 1:41 PM Gordon Messmer <gordon.messmer at gmail.com> wrote:
> On 12/23/20 12:26 AM, Mark Mielke wrote:
> > hat? .28.1 wasn't in 8.3. Check the changelog for 4.18.0-240.1.1.
> > Where did it come from? Oh right. It's called a branch.
> That's right.  Because it comes from RHEL, where point releases are
> branches.  That's what we keep saying: RHEL point releases are branches.
> That's right.  CentOS major releases are flattened.  That's what we keep
> saying: There is only one supported branch in CentOS at any given point
> in time.
> That's all that Matthew was pointing out, really.  If you have an
> application that needs an ultra-stable base OS, with security updates
> but no new features for more than (roughly) 6-8 months, Red Hat can
> provide you with such an OS.  CentOS doesn't.

I see hope at the end of this tunnel. You admit that RHEL minor
releases are branches. You admit CentOS is a flattened represention of
the RHEL minor release branches, which means that CentOS is composed
of concatenated set of RHEL minor release branches plus de-branding.
And, you agree that "If you have an application that needs an
ultra-stable base OS, with security updates but no new features for
MORE than (roughly) 6-8 months, ..."

So, please admit that if you want a stable base OS release, with no
new features, for *less* than 6-8 months, then this is exactly what
CentOS is.

Name one person that claimed that CentOS is supported beyond the
active release. Nobody did. The claim was that CentOS is based of RHEL
minor release branches, and this makes the effect the same as RHEL
minor release branches. That is - Red Hat branches the RHEL minor
release. Red Hat backports from X.N+1 and X.N+2 only as necessary to
X.N. The X.N patch set makes in into CentOS via imports. The imports
are serialized, just like *any* build system might become serialized,
but this is an artifact of the process, it is not indicative that the
content is not branched.

Your only point centers around how the serialization process doesn't
generate any late branching. This is an irrelevant point. Nobody said
it said. It has no impact on the result, which is that we have
branched content visible both in the source (which is not the CentOS
Git repositories... the CentOS Git repositories are *part* of the
process, they are not the original source for the process), and the
destination. Anybody can see these as branches:

https://vault.centos.org/8.0.1905/
https://vault.centos.org/8.1.1911/
https://vault.centos.org/8.2.2004/
https://vault.centos.org/8.3.2011/

It walks like a duck, and it talks like a duck. It has duck as a point
of origin, and when you cook the duck in an oven, it tastes like a
duck. But sure, for a section of the process known as "CentOS import,
de-branding, build, and release" it becomes serialized.

Ironically - RHEL minor releases become serialized in the very same
way. It's ironic, because you keep saying it's different - but you
have no evidence that it is different.

Everything you say about CentOS applies to RHEL:

> That's all that Matthew was pointing out, really.  If you have an
> application that needs an ultra-stable base OS, with security updates
> but no new features for more than (roughly) 6-8 months, Red Hat can
> provide you with such an OS.  CentOS doesn't.

I know you think RHEL EUS is "a separate support offering, and not
actually different". But, just as CentOS does not have these "extended
updates" in the CentOS repository (meaning as you believe "there is no
branch"), the main BaseOS and AppStream repositories for RHEL also not
have these "extended updates". With the exception of build environment
problems, and specific packages and package updates, which Red Hat
chooses not to import into the CentOS Git repositories, the set of
packages available in the CentOS repositories and the set of packages
in the RHEL repositories are 1:1, with the only delta being
de-branding.

What you say above, about "more than (roughly) 6-8 months", requires a
different subscription type, and a different repository. Whether it is
the same branch in the backend for RHEL as RHEL EUS? It doesn't really
matter. It is only the effect that counts.

The effect is that CentOS = RHEL for most real-life measurements,
including how the release was initially baselined, and which
backported source changes make it into the release. This is because
CentOS is imported from RHEL.

CentOS Stream is a different thing, as while CentOS = RHEL, CentOS
Stream does not match ANY RHEL release branch.

But, I think this has to be my last attempt to instruct you on this.
You are free to believe whatever you wish. Other people know how this
works, and understand that CentOS Stream is different. If you think
it's the same thing - good luck.

-- 
Mark Mielke <mark.mielke at gmail.com>