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

On Sun, Dec 20, 2020 at 10:19 PM Mark Mielke <mark.mielke at gmail.com> wrote:
>
> 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>



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