CentOS - Dec 2020 - https://blog.centos.org/2020/12/future-is-centos-stream/

On 12/8/20 6:18 PM, Pete Biggs wrote:
> On Tue, 2020-12-08 at 17:54 -0500, Matthew Miller wrote:
>> On Tue, Dec 08, 2020 at 03:15:17PM +0000, Pete Biggs wrote:
> 
>>> "CentOS will become the developer playground"
>>
>> This one is categorically not the case. Even Fedora isn't a
developer
>> playground. Everything landing in CentOS Stream is actually *planned*
(with
>> emphasis intentional) to go in a future RHEL release.
> 
> It's all the talk of SIGs and developing and testing and that Stream
> will be the centerpiece of that. That's what I meant. 
> 
>>
>> Previously, all the development around RHEL releases was done in
secret, in
>> the Red Hat black box. Now it's out of the box and can be watched.
There may
>> be some launch pains, but I expect the average quality of an update
hitting
>> CentOS Stream to be very high.
> 
> I don't get that from the documents released today.  If Stream is *not*
> a test-bed, then surely the code that appears in Stream must be fully
> formed in secret behind the scenes first. Yes, it will appear piecemeal
> rather than in one big chunk, but it has been categorically denied that
> Stream is not a RHEL 8.n+1 beta and is more a RHEL 8.n+1 RC/rolling
> release. 
> 
> 
> I think what a lot of people are concerned about is the rolling-release
> aspect of this. There will be no definitive versioning of CentOS in the
> future - all you will be able to say is "fully updated" and it
won't be
> possible to slot a CentOS system in to exactly match a RHEL version.
> Will third party RPMs built against RHEL 8.x be installable on a CentOS
> 8 Stream system? The answer is surely "it depends", but there are
a lot
> of hardware vendors that target drivers to RHEL releases, which may
> well make CentOS non-viable for hardware that doesn't have drivers
> built in to the kernel.
> 
> I suspect that for a large proportion of scenarios Streams will be
> perfectly OK. But we still get software/instruments that specifically
> say "only RHEL 7.4" or something like that (yes, it's a
support
> nightmare).  
> 
It is not the same as Rawhide is all I am saying.

It is based on the current release and it is being modified for some reason.

That modification can be a bugfix from a reported bug, it can be an
enhancement for a given package or it can be a security update.

Each of these updates will be rolled in one at a time.

It is what will eventually become the next rhel source code in a few
months for the next point release.

Only you will know if this will work for your situation.

We do have CI testing, which will be beefed up to be similar to the
testing RHEL actually does right now before release of packages for the
'released version' of RHEL.

Will bugs get though .. sure, they do now into RHEL.

But I will absolutely say that the things they are rolling into RHEL 8.4
in a few months are not inherently less stable or less secure or
whatever else you want to call it .. when compared to other Linux distros.

The process that Debian would use to roll in bug fixes or Ubuntu would
use to roll in bug fixes would not be significantly better or more
stable or more secure.

> 
> It is not the same as Rawhide is all I am saying.
> 
> It is based on the current release and it is being modified for some
reason.
> 
> That modification can be a bugfix from a reported bug, it can be an
> enhancement for a given package or it can be a security update.
> 
> Each of these updates will be rolled in one at a time.
> 
> It is what will eventually become the next rhel source code in a few
> months for the next point release.
> 
> Only you will know if this will work for your situation.
The problem is that we won't know if it will work.  When CentOS matched
the RHEL point releases we knew that an RPM/driver targeted for RHEL
8.2 has a good chance of working on CentOS 8.2 - but that versioning
match is lost with Stream. So vendors will either have to produce
another version of their RPM for CentOS 8 Stream (and continuously
check to see if it needs to be updated) or, more likely, just not
bother to support CentOS.  It already happens - HPE won't support
CentOS, but they do support RHEL and those RHEL RPMs work with CentOS.
The only Linux they support is RHEL, so we're stuck with our HPE kit. 
> 
> But I will absolutely say that the things they are rolling into RHEL 8.4
> in a few months are not inherently less stable or less secure or
> whatever else you want to call it .. when compared to other Linux distros.
So instead of keeping everything back for a point release, the packages
are set free once they are ready. Stream is a rolling release. And
that's fine, but it's not what people thought they were getting when
committing to CentOS. It has always been promoted as point release
compatible with RHEL and that was it's main attraction to many people.

A separate question. Will a point release of RHEL 8.x be directly a
snapshot of 8Stream on a specific date? Or will RedHat pick and choose
which versions from 8Stream they put into 8.x? i.e. Would it be
possible to clone the 8Stream tree on the date that, say, 8.6 is
released and call it 8.6.stream - would 8.6 be the same as 8.6.stream?


P.