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

> On 12/22/20 11:57 PM, redbaronbrowser via CentOS-devel wrote:
>
> > To reassure the community there is an FAQ with the following:
> >
> > > “CentOS Stream will be getting fixes and features ahead of RHEL.
> > > Generally speaking we expect CentOS Stream to have fewer bugs and more
> > > runtime features as it moves forward in time but always giving direct
> > > indication of what is going into a RHEL release”
> >
> > This is a complete reversal on a fundamental concept stated earlier by
> > CentOS.  Previously the mission was to close the COMPATIBILITY gap by
> > NOT “extending or enhancing packages or features.”
>
> At this point, I think you should be more clear than you are being. 
> CentOS Stream will be getting features intended for RHEL, earlier than
> RHEL.  This creates a temporary forward compatibility gap.  RHEL might
> not run software that was compiled on CentOS Stream, until those new
> features actually appear in a later RHEL release.  This same
> compatibility gap exists between point releases of RHEL.  If you build
> an application on RHEL 7.8, for example, it might not run on RHEL 7.7.
>
> On the other hand, CentOS Stream will be backward compatible with RHEL. 
> Anything that runs on RHEL should continue running on CentOS Stream.
>
> > But Red Hat is clever enough to rename “Rawhide” to “Stream” to make
> > it sound better.
>
> No, Stream is not Rawhide.

Well, Stream is not CentOS either given it doesn't strive for binary compatiblity which has been the defintion of CentOS.

Here is an example of how CentOS Stream has more in common with Rawhide than it does with CentOS:

Say CentOS 8 has a software release number 127 which has a bug.  There was at some point a release number 127 with the same bug that was part of RHEL.

But say CentOS Stream has a software release number 127 with a bug.  This may result in RHEL getting release number 128 and never getting release number 127.

Rawhide also has software release numbers that only appeared in Rawhide but never appear in RHEL.  You want to say the name is different, that is fine.  It still acts more like Rawhide.

In terms of being more clear, here is some key points:

The announcement of what would and would not change about the governance by CentOS joining Red Hat is here:
https://forums.centos.org/viewtopic.php?t=44407

It says the board would remain public, open and inclusive.  The new EOL date for CentOS 8 was made by a board that provided no transcript or chat log.

It says CentOS and the RHEL team would have a "firewall" between them.  All communication between them would be only via SRPM.  Brian "Bex" Exelbierd's inclusion on the board is a clear violation of that.

Karsten Wade justifies the actions of this invalid governance board by claiming seven times this is about the "openness gap."  However, that gap was created by Red Hat policy.  The RHEL team should have been able to make public RHEL builds ahead of time whenever they wanted to without needing CentOS to do it.

Even worse, despite Wade's claims of seeking to be "open," the Red Hat design of pre-applying the kernel patches into a tar-ball will continue.  If Red Hat really wanted to close the openness gap, it should start with fixing this bizzar policy that makes it hard to track down exactly which patch introduces bugs.