On 12/13/20 5:48 AM, Gordon Messmer wrote: > 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? Do not turn this upside down. Many obviously smarter then me saw this coming. Us more gullible believed when corporation told us nothing will change, while they took control of entire project. Death by thousand cuts is always more preferable by corporations, less bad PR. And they are not sign of doom but death, but of only this particular clone, others will take it's mantle. The reason I an agitated is I believed and with all my hearth supported this project, and now is owned by heartless profit-driven corporation.... > > >> 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. Don't be silly. They wanted to control the process, and to prevent anyone else from cutting into their process. You should read their manifesto for stream, only RH employees will be able to change that code, others will only be able to report bugs/issues and to sit and watch what RH does with them. Only real difference with stream is for those few hundred developers that are developing software that runs on RHEL so their code can be deployed as soon as new point release is launched. And even that RH does more for it's own gain, so that (opensurce?) projects/software important to RH can be deployed without delay, lest users ditch RH and go elsewhere. > > 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.) When people are happy with something they do not voice their content on the mailing list, mailing list is only to voice your discontent. You heard about "silent majority", right? Ever though why it is called that? > > >> 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. Not misinformed, I was part of that discussion 9 years ago, but my memory was little rusty, but I was part of that discussion and It did not bother be to track down one of the comments about kernel tarballs being published as monolith code vs trackable patches, to make problems for builders of RHEL clones: "There is the kernel tarball issue. That's understandable, but real. Red Hat is publishing their kernels as tarballs, rather than as the vanilla tarball with a list of ordered patches against it. This makes layering in, or out, specific patches much more awkward. Was Oracle being any better about this? Does anyone have actual pointers to their SRPM's?" (https://lists.centos.org/pipermail/centos-devel/2011-March/063442.html) > > 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. Point is that RH DID slow down build of clones due to this change, and for several months. I can not say about intent, but in hindsight it fits the pattern, I even thought the same back then (mail in link was direct reply to my mail). > > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos -- Ljubomir Ljubojevic (Love is in the Air) PL Computers Serbia, Europe StarOS, Mikrotik and CentOS/RHEL/Linux consultant