On Thu, Jan 21, 2021 at 12:16 PM redbaronbrowser via CentOS-devel centos-devel@centos.org wrote:
On Monday, January 4, 2021 8:17 AM, Rich Bowen rbowen@redhat.com wrote:
I think I need to revisit this response at this point.
It's important to note that, yes, the Red Hat Liaison has (more accurately: can have in certain circumstances) a louder voice than most other participants. This is something that needs to be stated clearly and kept in mind, however much it may annoy some folks. Red Hat is paying the bills and so has a louder voice.Some of the people paying the bills are the ones paying an additional $1,200 per Red Hat OpenStack hypervisor per year to get licenses to run RHEL guests.
Do they get a louder voice for paying the bills?
Red Hat's louder voice is based on two different components. The primary form of this "louder voice" is that Red Hat employs a ton of engineers who contribute directly to the CentOS Project or the codebases that become elements of CentOS Project outputs. We speak loudly in the sense that we can choose what we do and what we don't do. In the same way committers in a project have a louder voice than other contributors as they decide what the project will and will not do. This is the way Open Source works.
The other aspect is that Red Hat has a veto over the project. We also have one in Fedora. It exists primarily as a liability control switch. Because the projects don't have separate legal entities we need to be able to protect the company. These vetos have never been used and have not been envisioned to be used for technical decisions.
Extending this metaphor, as you have, Red Hat customers do have a louder voice. As a customer you have the opportunity to influence Red Hat and therefore by extension influence the decision of what Red Hat employees are asked to do. This advantage is enjoyed by any enterprise which has their employees contribute to open source.
Or is the "elephant" that Red Hat now endorses three other public clouds of which *NONE* are running Red Hat OpenStack as the method people should get their free RHEL licenses?
I don't understand this statement. The announced programs are accessible in any cloud which supports cloud access. If someone has a cloud that doesn't support cloud access, have them talk to us at CentOS-questions@redhat.com. We can figure out what the challenges are and see if we can get them into the program.
After buying a product from Red Hat stated to be for providing public and hybrid clouds, is Red Hat providing them a fair way to compete? Or is Red Hat gaming the system to undermine their own customers--the same ones that have already paid the bills?
see above. Cloud access isn't a new program.
I understand Red Hat may have additional announcements. But the damage is already done. The message is clear that Red Hat endorses three major clouds and those that run Red Hat OpenStack aren't worth endorsing.
Did the people paying the bills really get a louder voice?
So, yeah, we (and, here, I would point largely to Karsten) have been actively working and discussing governance issues for the past 2 years. Should we have been more open about this? Sure, I think the answer to that question is always yes. Indeed, I tend to annoy people with my pushes for transparency around everything, but, of course, it's a balance in a project, like CentOS, where it's largely controlled by a single company. This, in turn, is why I see Stream as such a positive step - it gives the reins, at least a little more, to you, the community.What is the criteria for success for giving the reins that was discussed at the November 11th meeting?
How was it determine that criteria for success would be achieved by December 31, 2021?
That said, I understand and empathize with the frustration and anger from the community around this change. But what I have been saying consistently since that change is that, as annoyed and frustrated as we all are, it is critical that we acknowledge that the change has happened, and figure out What's Next. I hope that everyone who wants to stay around to help figure that out is able to do this without blaming individual board members, calling for resignations, and other unhelpful personal attacks.I never was attempting to make personal attacks. I am trying to figure out how we got to this point. Is there people that had a conflict of interest in deciding December 31, 2021 is a deadline by which Stream will reasonably replace CentOS 8?
The board didn't change to set this up. Additionally Red Hat has published how its employees are freed to act in open source projects. Those guidelines may help you understand the lack of conflicts of interest. Further, part of the reason I was brought in as the Red Hat Liaison was to create clarity where previously there had been some confusion. My appointment included an explicit statement that I will speak for Red Hat, and only for Red Hat, i.e. without a personal voice, to ensure that when Red Hat something to say people could know it was Red Hat. This provided freedom for Karsten, the previous Liaison to act personally, which he had spent a lot of time doing anyway, without it being perceived that his opinions were Red Hat's or dictated to him.
Let me put this another way. Mark Shuttleworth has given interviews stating his product has never missed a release date. There is several bugs in Lauchpad that indicate major issues with the installer and other primary components were never addressed (including in LTS releases). Bugs that can be confirmed to still exist when the product never missed it's release date. Is there ever a point in which it stops being a personal attack to say someone that takes pride in that situation is toxic to the brand and the results?
To be clear, I am not saying anyone on the board is identical to that person. I am saying what Stream is has been misrepresented as part of claiming the board decision mades sense. And seems to be preceeding with no criteria for success when esablishing the date of completion.
Consider the following: "Does this mean that CentOS Stream is the RHEL BETA test platform now? A: No. CentOS Stream will be getting fixes and features ahead of RHEL. Generally speaking we expect CentOS Stream to have fewer bugs and more runtime features as it moves forward in time but always giving direct indication of what is going into a RHEL release"
Does that indicate people should expect bugs that would fail established Fedora release criteria to be part of Stream?
Or Karsten Wade's labeling of an blog post on testing with "Stream can cover 95% (or so) of current user workloads" -- does that frame Stream in a way that people should expect bugs in which a Fedora Go / No-Go meeting would push off the release?
Because CentOS Stream doesn't have releases, there is no ritual of go/no-go meetings or release criteria, per se. Instead we have acceptance testing built from the same tests used on RHEL releases to establish that the code isn't WIP or otherwise an experiment. There will always be bugs, that is the nature of software. We are saying that bugs in CentOS Stream will be the result of actual bugs, not because someone pushed something half-baked that we knew was broken.
regards,
bex