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>