On Mon, 24 May 2021 at 04:48, redbaronbrowser via CentOS-devel < centos-devel@centos.org> wrote:
On Sunday, May 23, 2021 7:31 AM, Neal Gompa ngompa13@gmail.com wrote:
You are conflating completely different things.
First, IBM isn't involved in anything around CentOS Stream. Red Hat has been very consistent about this. Many Red Hatters have confirmed this over and over. If they were lying, they would be in considerable trouble for making such statements publicly.
I never said they are lying. It has been stated by Red Hat employees on this mailing list that Red Hat now has a special partnership with IBM. That should include having the contacts to speak on behalf of the CentOS project.
Anyone with past experience with IBM for anything longer than a year soon realizes that IBM is a hydra. There is no one legal department and many of its divisions have independent rules about what they will allow even other 'divisions' of IBM to use. It usually takes years of negotiations for those rules to be worked out and any exceptions to be made... and no one outside of a small group of people are even aware that those negotiations are going on with extra NDA added in. [And there may be multiple teams doing the same negotiations only to find out about each other after deals have been done.] So if said things were being done, I doubt that a) many of the Red Hat people on this list know about it and b) those that could would be able to say anything under contract penalties. **
** Note this is not unique to IBM. Any company over 50k in people seem to go this route as humans try to simplify social constructs too complex for our monkey brains to deal with.
I'm not asking RH to assist in getting Oracle to relicense ZFS. I perfectly understand they don't have friendly relationship with Oracle. I wouldn't consider it fair to expect RH to assist with that. It is not my intention to ever push for OpenZFS inclusion.
However, in this specific instance for this specific kernel module, I think it is fair to say RH has a friendly relationship with IBM.
I'm personally getting very tired of how you keep doing this on the list. You don't disclose anything about yourself and you continue to attempt (and in some instances, succeed) at gaslighting the CentOS community. You're stoking the flames and I'm increasingly suspicious that you're trying to make this fail. I would appreciate it if you started operating in good faith rather than whatever you're doing now.
My understanding of "gaslighting" is promoting something the author knows to be false.
My key concern has been the openness gap for the Stream 8 kernel. If it was up to me then my focus right now would be kpatch and testing applying increments starting from the CentOS 8.3 release 240 of the kernel.
However, here is the commit history on gitlab for the Stream 8 kernel:
https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-8/-/commits...
It is *one* commit. There is no history of incremental changes.
So, was I "gaslighting" when I raised the concern that there is still an openness gap with Stream 8 and the Stream 8 kernel? Was I saying something I knew to be false?
Is gitlab presenting a series of individual commits for the Stream 8 kernel and proves I have presented a false concern?
I think one reason is that people feel they have explained this several times, and from my reading you say 'ok I understand' but then come back later asking the same questions as if no one had tried this before. That makes it easy
8 Stream currently works differently from the proposed stream model. This is because it was done as a proof of concept and a lot of those got baked into legal and other procedures. The way patches** enter are this way:
[Red Hat packager] -> [Internal Commits] -> [Testing] -> [Bundle and push to 8-Stream git] -> [Builds] -> [CentOS 8 Stream]
9 Stream goes with
[Red Hat packager] -> [Public commits to gitlab] -> [Testing] -> [Builds] -> [CentOS 9 Stream]
** I am cutting out the forking off into internal which happens at different points but looks like crap in an email.
The original idea for 8 was that Red Hat, Fedora and CentOS would share the same git repository using pagure using a cluster technology. However this was causing a lot of problems after 8 was released, and it was decided that having Red Hat and CentOS share stuff in an external managed git repository. This took a lot of time so that it was only in 'production' within the last 6 months. By that time, it was time to put most of the work focus on EL-9 so that has been the main focus to get things done. When 9 is out the door then 8-stream can be retrofitted into a similar plan as there are a lot of paperwork which has to be updated and approved for various certifications, legal filings, and such. That takes time.
To summarize, 8-stream is going to have blobs of patches show up for the time being.