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

Mon Dec 21 03:19:21 UTC 2020
Mark Mielke <mark.mielke at gmail.com>

On Sun, Dec 20, 2020 at 6:34 PM Gordon Messmer <gordon.messmer at gmail.com> wrote:
> On 12/19/20 8:27 PM, 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.
> > Are you saying the
> > CentOS point releases do *not* match as closely as possible the
> > corresponding RHEL point release?
> No, no one is saying that.  Matthew said that you can stay at a minor
> release of RHEL and still get security updates.  CentOS does not offer that.

This is not correct. Please stop saying it. CentOS is bug-for-bug
compatible with RHEL for *active* releases.

If you disagree with me that CentOS is bug-for-bug compatible with
RHEL for *active* releases, then please provide a real life example.
Otherwise, stop saying this rubbish.

> In RHEL, a minor release is a branch.  You can install RHEL 7.8, and
> keep a host on RHEL 7.8 until the end of its life cycle.  If you want
> long term support for an OS with minimal changes, but continued support,
> that's a thing that RHEL provides.

You can also install CentOS 7.9, and keep a host on CentOS 7.8 until
the end of its life cycle. That is what RHEL is. If you can prove
otherwise, then please prove it. Show us an example of where this is
not true.

You and Matthew are confusing RHEL with RHEL EUS. They are not even
the same subscription type! Somebody who buys RHEL, is not permitted
to access EUS, without either having a Premium subscription, or a
separate EUS subscription.

As I said - provide an example. Otherwise, please stop misinforming people.

> CentOS doesn't offer that.  If you're using CentOS, you're always on the
> "latest" branch.  You either apply feature updates that come with each
> point release to get security updates, or you stop applying updates
> entirely and run the risks that come with not applying security or
> bugfix updates.

This is false. As I showed real-life examples for. Please provide your
own counter-examples for an actual discussion, rather than your own
uninformed opinion.

> Mark is confusing the issue somewhat.  I *think* he is trying to say
> that when we say that CentOS point releases have no branches, we're
> saying that there's no QA, which is absolutely not what we're saying.
> We're not talking about the back end development process, we're talking
> about the products that are delivered to customers.  Customers can
> choose what branch of the RHEL product to deploy on their systems, and
> how long to use a given point release.  CentOS users don't get that
> level of support.

This is also false. Moving CentOS from "downstream" to "upstream"
absolutely affects where QA fits into the process. This is a
fundamental thing that is being ripped out from under you - and you
don't even realize.

Let's say there is a process to properly "bake" an Enterprise Linux
release. It includes a number of steps, which I have outlined in prior
posts. CentOS as it was originally created, and as existed until
CentOS 8, was to take the output of this finished process and
reproduce it bug-for-bug. Essentially RHEL baked a cookie, and CentOS
baked a cookie, and the outcome is the exact same except one says
"baked RHEL" and one says "baked by CentOS".

CentOS 8 Stream, is the output at an earlier stage in this baking
process. In this analogy, I would equate CentOS 8 Stream to something
like the batter. It's a necessary component to baking the cookie, but
it is an unfinished product.

In this analogy, you - and a few others like you - are eating the
batter and saying "tastes like cookie to me! good job, Red Hat!" But,
you don't even realize the value of RHEL. You don't realize that you
previously had a finished cookie, but now you just have the cookie
batter because Red Hat is not baking it for you. They are just giving
you the batter.

One day - the light bulb will go on, and you will be "omg... I just
realized what Mark was trying to tell me."

Or, maybe not.

Mark Mielke <mark.mielke at gmail.com>