On Sun, Dec 20, 2020 at 2:21 PM Matthew Miller <mattdm at mattdm.org> wrote: > On Sun, Dec 20, 2020 at 12:21:48AM -0500, Mark Mielke wrote: > > I'm pretty sure Matthew Miller is talking about EUS releases, and he > > is missing that all RHEL minor releases are actually branches whether > > EUS or not. Red Hat is developing N+1, and N+2, while publishing N, > > and mirroring N to CentOS 7 and 8. I covered this in more detail in my > > other posts. > I am a little confused by your messages on this topic. You are vehemently > telling me that I'm missing something and don't understand, while you > explain in greater detail the same thing I said: RHEL minor releases are > actually branches, while CentOS Linux rebuild minor releases never were. The obvious answer is that I don't think we are saying the same thing. Let's go back to your original response to me: > > 2. Minor release milestones to stabilize branches. We have breakage > > with most minor release upgrades, and the stabilization process is an > > important method of isolating users from being affected by this. This > > is why CentOS 8 Stream is being said "for developers", while RHEL 8 > > would be "for production". It is being said, because it is a real > > thing. If you truly believed minor release milestones were unnecessary > > for CentOS 8 Stream, then you would also believe that minor release > > milestones were unnecessary for RHEL 8. >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. For CentOS Linux, a minor release is >a point where updates pause for a while while the team scrambles to rebuild >a large update of many packages and then those packages all updated in a big >chunk _on the single CentOS branch_. So this is always been extra value that >Red Hat Enterprise Linux provides that CentOS Linux did not mimic. I claimed CentOS Linux was superior because it provided "Minor release milestones to stabilize branches". You claimed "It's important to note that the CentOS Linux rebuild never actually had this." Your conclusion is not correct, for the reasons that I outlined in other responses. As I respect you too much to believe that you are playing word games, I am presuming this is a genuine misunderstanding, which is why I spent considerable effort detailing examples, including Firefox ESR breakdown of impact, to explain why what you are saying does not match what I am saying, and why what I am saying matters. Let's go into closer detail on your claim, snipping specific sections to help dissect: >RHEL minor releases are actually branches, and you can stay at a minor >release and still get security updates. For CentOS Linux, a minor release is >a point where updates pause for a while while the team scrambles to rebuild >a large update of many packages and then those packages all updated in a big >chunk _on the single CentOS branch_. The CentOS Linux branches are imports from the RHEL minor release branches. You can see this by looking at the history of them, and comparing the versions that are published to CentOS Linux, and the versions that are published to RHEL for any given minor release. The "c7" branch looks more like this: |-- ... --|-- RHEL 7.0 branch imports + de-branding --|-- RHEL 7.1 branch imports + de-branding --|-- ... --| Technically this is exposed as one branch called "c7", but this is a flattened set of outputs. Essentially, "c7" is *not* a source branch. It is the serialized result of performing a process against a set of more complicated branches. This means that to say "RHEL minor releases are branched, CentOS minor releases are not" is to ignore that CentOS = RHEL + De-Branding, and that the CentOS branch is an export for the RHEL branches. Therefore, for an *active* release of RHEL/CentOS, this statement you made is false: >So this is always been extra value that >Red Hat Enterprise Linux provides that CentOS Linux did not mimic. This is *not* an extra value of RHEL over CentOS. The extra value of RHEL over CentOS, is *support*. What you are, however, referring to, perhaps by accident, or perhaps by misunderstanding, is RHEL EUS. For RHEL EUS, your statement becomes correct: >So this is always been extra value that >Red Hat Enterprise Linux *Extended Update Support* provides that CentOS Linux did not mimic. I think there is a large section of people that do not understand the difference, and therefore they do not understand exactly what the different between CentOS Linux and CentOS Stream represents. These people don't understand what is being lost with CentOS Stream, and they will be a little shocked when they find out. Fedora doesn't do this. Fedora breaks this with smaller incremental major versions. Fedora is very similar to CentOS Stream, and as such, I can see why you would be comfortable with it. -- Mark Mielke <mark.mielke at gmail.com>