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.