Am 19.12.20 um 18:49 schrieb Nico Kadel-Garcia: > 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. IIRC thats the reason why CentOS Linux has a kickstart directory in the repo tree. > 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. > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel > -- Leon