[CentOS-devel] Balancing the needs around the RHEL platform

On Thu, Jan 21, 2021 at 12:16 PM redbaronbrowser via CentOS-devel
<centos-devel at centos.org> wrote:
>
> On Monday, January 4, 2021 8:17 AM, Rich Bowen rbowen at 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 at 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

-- 
Did this email arrive after work for you?  Stop reading it and enjoy
some work/life balance.

Brian "bex" Exelbierd (he/him/his)
Community Business Owner, RHEL Product Management
@bexelbie | http://www.winglemeyer.org
bexelbie at redhat.com