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>