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

On Sat, Dec 19, 2020 at 3:28 PM Gordon Messmer <gordon.messmer at gmail.com> wrote:
>
> On 12/19/20 1:34 AM, Mark Mielke wrote:
> > However, these are significant reasons why CentOS Linux is superior to
> > CentOS Stream:
> >
> > 1. Bug-for-bug compatibility with RHEL. This is important or a variety
> > of reasons, particularly including reproducibility.
> > 2. Minor release milestones to stabilize branches.
>
>
> Reproducibility *is* important.  Minor releases, however, are not
> necessary to achieve reproducibility, nor are they sufficient. Red Hat
> does fix bugs within minor releases:
>
> https://access.redhat.com/errata/#/?q=&p=1&sort=portal_publication_date%20desc&rows=10&portal_advisory_type=Bug%20Fix%20Advisory&portal_product=Red%20Hat%20Enterprise%20Linux
>
> Therefore, if you operate an environment where reproducibility in your
> test environment is a critical feature, you should be testing and
> deploying on the *same* underlying OS.  Maybe that means you test and
> then deploy gold images, or containers.  Immutable infrastructure is
> popular for good reason.

This will be *much* harder with CentOS Stream only. The point
releases, much like RHEL point release mdeida which they effectively
mirrored, provide a stable release tag to work from From the
description, this is being discarded entirely.

> If you have mutable systems, there's no mechanism to keep CentOS and
> RHEL packages perfectly in sync.  You're not actually getting

They never were, and they never will be unless Red Hat returns to what
it did before RHEL and publishes precisely the same packages available
to the public without an extra release team.

> reproducible builds out of that setup, even if you think you are. It

The point releases were a solid starting part. There has been a push
from Red Hat to get customers onto a "streaming release" model, and
especially to encourage people to pay for RHN  to do host-by-host
package installation tuning. I don't know anyone who likes it. I've
gotten years of consulting work for big companies keeping *away* from
spending all their time hand-tuninging individual package-by-package
tuning with RHN.

> doesn't make a good argument in favor of keeping CentOS.

Same RPM tree, defined package list, defined build material, golden
images for media or PXE installation and for generating build
environments from scratch.  This predated mock: I deployed
approximately 13,000 hosts in one month this way.

> > I don't agree with you that CentOS cannot be two things. It's quite
> > normal for most projects to have an "upstream" and a "LTS" branch.
>
>
> Fedora is the upstream branch.  CentOS Stream is the LTS branch. RHEL is
> the LTS branch with point releases (semantic versioning) and vendor support.

I'm staring at the announcement at https://centos.org/distro-faq/,
which blatantly contradicts:

     Q5: Does this mean that CentOS Stream is the RHEL BETA test platform now?

     A: No. CentOS Stream will be getting fixes and features ahead of RHEL.

There's a Greek word for that. It's spelled "B-E-T-A". I soo no
assurance that anything in CentOS Stream will ever make it to RHEL,
and I expect such discarded or retuned binaries to be a real source of
pain. I expect to be particularly awful when a client-driven patch for
commercial RHEL is split-brain with ongoing patches or development in
CentOs Stream. If you think tha tcan't happen, I'll point you to the
kernel patches for ext2 optimization in the days when I worked for CDN
companies.