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

On Wed, Dec 23, 2020 at 5:43 PM Gordon Messmer <gordon.messmer at gmail.com> wrote:
> On 12/23/20 2:00 PM, Mark Mielke wrote:
> > 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.
> You're using the word "admit" as if that wasn't the point that Matthew
> was making to begin with, which you and Nico argued against.  (In
> response to Matthew, Nico wrote "No. RHEL minor releases are more like
> source control "tags" than branches."  I wrote that Matthew was correct,
> and you replied "This is false...")

In hindsight... I should have qualified. The first thing I said
"false" to, was that Nico should stop talking and "listen" because he
might "learn something". I recognized in Nico's words that he knew
exactly what he was talking about, and I did not agree that he should
stop talking and "listen" because he might "learn something". I wish
he would speak more.

> > 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.
> It's pretty close, with one significant caveat: for (roughly) two months
> out of the year, CentOS doesn't get any updates at all, including
> security patches.  For me, that's an awfully big risk. I would much
> rather get features on a regular basis than go without security patches
> for a month, twice per year.

Yes! Finally some common ground! We both agree that CentOS Linux is a
*stable* OS with security patches and backports for the "6-8 month(s)"
period that the minor release is active. We both agree that the CentOS
program had difficult with new releases, which did mean that in
general it always runs behind RHEL by weeks to months. With the
exception of high priority security fixes, basically the whole program
is initially delayed by a longer amount, and then catches up, but
remains behind by a few weeks. With the exception of build environment
issues, CentOS and RHEL run in parallel, with CentOS slightly behind
RHEL.

If anybody wants *support* for the active release, they should
probably not use CentOS. They should use RHEL, or another vendor that
provides *support*.

If anybody wants *patches* for prior releases, Red Hat runs a Extended
Update Support program which costs extra (or comes for free with
"Premium") that extends the life of the minor release up to about 2
years after the minor release was first published. Red Hat runs
additional programs (at higher extra cost) for support beyond this two
year period.

If people find CentOS acceptable to their requirements, it was an
excellent choice. If it was not acceptable, they would have found
something else.

> Personally, I think it's irresponsible to make the claim that CentOS is
> 1:1 with RHEL.  It isn't.  RHEL is supported all of the time.  CentOS is
> supported during (roughly) 10/12 months of the year.  Now, you're free
> to decide that the 10/12 month support SLA is good enough for your
> business, and you can say so.

It might be, or it might not be. We all make choices. It sounds like
you are considering going forwards with CentOS 8 Stream. Personally, I
would consider this irresponsible. However, we all have different use
cases, priorities, and internal capabilities, and what is
irresponsible for one person, might be perfectly acceptable for
another person.

I think Red Hat has talented people that could solve this problem.
Simply, it was not a business priority. However you try to phrase it -
fundamentally, it was not in Red Hat's interest to make sure CentOS
was released simultaneously with RHEL. Technically possible, but there
was insufficient business incentive. Now, if we compare to something
like Oracle Linux, Oracle Linux is also delayed - but in some cases,
the delay is as little as 6 days. I refuse to believe Red Hat couldn't
achieve this, so I'm left to believe they didn't care to. :-)

> That's fine.  But these threads drag on
> at length because when we discuss the benefits that come with giving up
> the point release in favor of continuous delivery of updates, you start
> shouting "this is false! this is false! this is false!"

I didn't say "benefits of continuous delivery of updates is false". I
said points you were making about how it compares to CentOS 8 were
false. You can make the case for CentOS 8 Stream, without making
misleading statements about CentOS 8. For example, above - it's
perfectly valid to say that CentOS 8 was delayed from RHEL, and this
may represent a serious security concern. This is a true statement.

I don't want to belabor this, as I really don't like getting so
frustrated as to have to tell somebody what they are saying is False.
But, I think it is important to point out that I am clearly in favour
of continuous delivery of updates for *some use cases*. You need only
read my other posts to see that I don't think CentOS 8 Stream is a bad
thing. But, I, and many other people - do not agree that it is a
drop-in replacement for CentOS 8, and I think the crux of this is an
accurate understanding of what CentOS 8 is. Not the pedantic
definition, nor the ignorant definition, but the practical real-life
experience of a large number of the users, and the carpet being ripped
out from under them. CentOS 8 Stream may be the future, but most of us
have to deal with the past. We don't have the luxury of living on the
edge.

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