On Mon, Dec 21, 2020 at 12:22 AM Gordon Messmer <gordon.messmer at gmail.com> wrote: > On 12/20/20 7:19 PM, Mark Mielke 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. > CentOS is compatible with the current release. I don't think anyone is > saying that it isn't. I honestly can't figure out why you're telling me > that I'm wrong and then arguing what seems to be a completely different > point. Unless... The point that is getting lost - is that CentOS 8 Stream is not the hardened release you think it is. CentOS 8 and RHEL 8 is. CentOS 8 is not. I've tried to explain the branching strategy to you, that should have made it clear to you that the "current release" is a branch, and it is not latest. But, we're not stuck in word games about what a branch is, or what a tag is, and you are totally missing the point. I think others do get the point, so we can just leave it at that. > > You and Matthew are confusing RHEL with RHEL EUS. > Are you objecting because you think that RHEL and RHEL EUS are different > products? I would have described EUS as a different support contract > for the same product, but at that point you're *really* parsing words > carefully. I'm objecting to you saying things that are not correct. "RHEL" and "CentOS" are equivalent today. "CentOS Stream" is not equivalent. "RHEL EUS" is what you are describing. If you want to claim that I am playing a word game about this, then this is another place where I think others will get the point, so we can just leave it at that. > >> 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. > I think that your position here implies that end-users who run beta > releases are responsible for the quality of Red Hat's releases, and I > don't know any reason to believe that. In particular, Red Hat employees > tell us that "literally almost nobody uses them": > http://crunchtools.com/before-you-get-mad-about-the-centos-stream-change-think-about/ > I don't have any reason to disbelieve that, so when I think about how > Red Hat is able to manage a high-quality release, I tend to think that > it's because they have a rigorous testing process for the software they > distribute, and they have repeatedly told us in this list that CentOS > Stream updates will have gone through that process. Red Hat never claimed that CentOS Stream will be just as hardened as CentOS. They never claimed it will get the same process. Doing so would make RHEL obsolete, so it's not even an intelligent thing for them to claim. This is more like wishful thinking. Good luck with your CentOS 8 Stream deployments. -- Mark Mielke <mark.mielke at gmail.com>