[CentOS-devel] Balancing the needs around the CentOS platform

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.