On Wed, Dec 23, 2020 at 1:41 PM Gordon Messmer <gordon.messmer at gmail.com> wrote: > On 12/23/20 12:26 AM, Mark Mielke wrote: > > hat? .28.1 wasn't in 8.3. Check the changelog for 4.18.0-240.1.1. > > Where did it come from? Oh right. It's called a branch. > That's right. Because it comes from RHEL, where point releases are > branches. That's what we keep saying: RHEL point releases are branches. > That's right. CentOS major releases are flattened. That's what we keep > saying: There is only one supported branch in CentOS at any given point > in time. > That's all that Matthew was pointing out, really. If you have an > application that needs an ultra-stable base OS, with security updates > but no new features for more than (roughly) 6-8 months, Red Hat can > provide you with such an OS. CentOS doesn't. I see hope at the end of this tunnel. You admit that RHEL minor releases are branches. You admit CentOS is a flattened represention of the RHEL minor release branches, which means that CentOS is composed of concatenated set of RHEL minor release branches plus de-branding. And, you agree that "If you have an application that needs an ultra-stable base OS, with security updates but no new features for MORE than (roughly) 6-8 months, ..." So, please admit that if you want a stable base OS release, with no new features, for *less* than 6-8 months, then this is exactly what CentOS is. Name one person that claimed that CentOS is supported beyond the active release. Nobody did. The claim was that CentOS is based of RHEL minor release branches, and this makes the effect the same as RHEL minor release branches. That is - Red Hat branches the RHEL minor release. Red Hat backports from X.N+1 and X.N+2 only as necessary to X.N. The X.N patch set makes in into CentOS via imports. The imports are serialized, just like *any* build system might become serialized, but this is an artifact of the process, it is not indicative that the content is not branched. Your only point centers around how the serialization process doesn't generate any late branching. This is an irrelevant point. Nobody said it said. It has no impact on the result, which is that we have branched content visible both in the source (which is not the CentOS Git repositories... the CentOS Git repositories are *part* of the process, they are not the original source for the process), and the destination. Anybody can see these as branches: https://vault.centos.org/8.0.1905/ https://vault.centos.org/8.1.1911/ https://vault.centos.org/8.2.2004/ https://vault.centos.org/8.3.2011/ It walks like a duck, and it talks like a duck. It has duck as a point of origin, and when you cook the duck in an oven, it tastes like a duck. But sure, for a section of the process known as "CentOS import, de-branding, build, and release" it becomes serialized. Ironically - RHEL minor releases become serialized in the very same way. It's ironic, because you keep saying it's different - but you have no evidence that it is different. Everything you say about CentOS applies to RHEL: > That's all that Matthew was pointing out, really. If you have an > application that needs an ultra-stable base OS, with security updates > but no new features for more than (roughly) 6-8 months, Red Hat can > provide you with such an OS. CentOS doesn't. I know you think RHEL EUS is "a separate support offering, and not actually different". But, just as CentOS does not have these "extended updates" in the CentOS repository (meaning as you believe "there is no branch"), the main BaseOS and AppStream repositories for RHEL also not have these "extended updates". With the exception of build environment problems, and specific packages and package updates, which Red Hat chooses not to import into the CentOS Git repositories, the set of packages available in the CentOS repositories and the set of packages in the RHEL repositories are 1:1, with the only delta being de-branding. What you say above, about "more than (roughly) 6-8 months", requires a different subscription type, and a different repository. Whether it is the same branch in the backend for RHEL as RHEL EUS? It doesn't really matter. It is only the effect that counts. The effect is that CentOS = RHEL for most real-life measurements, including how the release was initially baselined, and which backported source changes make it into the release. This is because CentOS is imported from RHEL. CentOS Stream is a different thing, as while CentOS = RHEL, CentOS Stream does not match ANY RHEL release branch. But, I think this has to be my last attempt to instruct you on this. You are free to believe whatever you wish. Other people know how this works, and understand that CentOS Stream is different. If you think it's the same thing - good luck. -- Mark Mielke <mark.mielke at gmail.com>