[CentOS] I'm looking forward to the future of CentOS Stream

On 12/11/20 9:56 AM, Ljubomir Ljubojevic wrote:
> And I will repeat that millions of CentOS users found free clone of RHEL
> trustworthy enough to use it for production, even without "official
> endorsement".


Exactly.  That's why it's so weird that those people, today, think that 
CentOS Stream won't be usable, based on their interpretation of the 
official statements from Red Hat.  Red Hat's statements weren't taken 
into consideration before, but now they're a sign of doom?


> If they ... even allowed ANYONE ELSE that was not employed by Red Hat in
> 2014 to even come close to learning the secrets of rebuild, no backlash
> would have happened


I'm going to stop you there, because the CentOS maintainers kept that 
process out of public visibility long before Red Hat was ever involved.  
If you think users should know more about the process, then you are 
pointing fingers at the *wrong* people.

I don't want this to become a flame war.  So rather than pointing 
fingers, let's focus on the fact that CentOS Stream promises to be 
developed in the open, resolving the problem that you're describing.

Red Hat is fixing the thing you're complaining about.

Red Hat is giving us the thing that has been requested more often, by 
more people, than any other change in CentOS, and the result is that the 
press is full of stories about users being angry, because five people on 
the mailing lists sent a lot of messages.  (About half of the traffic in 
the threads on centos and centos-devel comes from five people, and 
various people replying to them.)


> But no, as soon as Oracle started rebuilding RHEL source code Red Hat
> first made things difficult for everyone to create kernels (source code
> was not srpms anymore but tar?)


You're misinformed.  Kernels are still built from SRPM, but the archive 
used is no longer an upstream release with a series of patches.

The reason for the change is not insidious.  It's unfortunate that the 
pristine source + patches can't be maintained, I agree, but speaking as 
a developer: maintaining hundreds of patches that touch intersecting 
files and rebasing them all when earlier patches are updated is an 
incredibly difficult and time consuming task.  And, if I remember 
correctly, applying all of those patches took almost as long as building 
the kernel.  If it takes that long to just prepare the source code, 
that's a major hit to productivity when a developer needs to work on the 
code or build the SRPM to validate changes.

And, ultimately, there's very little value in shipping those patches 
when the vast majority of them are already in the current version of the 
upstream kernel, and they're merely backported to the older release that 
Red Hat supports.  It's an entirely different story when distributions 
are shipping patches that they don't push upstream, but that's not 
generally what you see with the kernel package.