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

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