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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
