On Sat, Dec 19, 2020 at 12:29 PM Matthew Miller <mattdm at mattdm.org> wrote: > > On Sat, Dec 19, 2020 at 04:34:53AM -0500, Mark Mielke wrote: > > 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 No. RHEL minor releases are more like source control "tags" than branches. They have stable installation images one can refer and start new deployments from, and ongoing work is branched from that tag. This has been the case since the earliest Red Hat, not even RHEL, releases since I encountered them back in 1995. > 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. Nothing personal, but "nonsense". See above. The PXE images and kernels in the installation media, in particular, mattered. I used to publish quite large Red Hat based deployments, and you *never* simply ran "yum update" from the live update streams at the time of building your new images or testing environments. It's why I published tools like my reposync scripts, to generate a lockable internal mirror and avoid the streaming update dangers without investing in the very large cost of an RHN setup. Having a stable repository for a full reference for updating an environment or especially build and testing environments synchronously is vital. It's also been very useful for "mock", since one can turn off the update channels and use the current of specific CentOS point releases for builidng software. If you're doing that with RHEL, well, frankly I'd use a locked down internal mirror. My reposync scripts and rsync tools are published at https://github.com/nkadel/nkadel-rsync-scripts . They're pretty easily linked to a filesystem that does hardlinks and allows snapshotting to produce a "current" and a datestamped, locked down copy of the repos, much like the old "rsnapshot" tool did for rsync backups. And I was a maintainer on that tool for a while, too.