[CentOS-devel] Vote of Confidence

Mon Jan 4 07:53:45 UTC 2021
redbaronbrowser <redbaronbrowser at protonmail.com>

On Sunday, January 3, 2021 11:36 AM, Matthew Miller mattdm at mattdm.org wrote:

> On Sat, Jan 02, 2021 at 11:51:35PM -0500, Mark Mielke wrote:
>
> > It is the charade of it all that is the most frustrating. For example,
> > saying that it is "upstream" so this will facilitate contribution, but
> > then admitting that actually Red Hat is still the upstream, and Red
> > Hat will make all the decisions on what content and direction is
> > allowed. At least Fedora has some ability to choose a different path,
> > like BTRFS as one example. Will CentOS Stream community members be
> > permitted to add BTRFS back into CentOS Stream? Or will Red Hat
> > prevent such a thing?
>
> It's not a "charade". You don't have to believe it, but everything we're
> saying is sincere.
>
> "Upstream" doesn't necessarily mean "community controlled upstream". This is
> common in a lot of open source projects with corporate backing. (I think
> Fedora is pretty special in this regard.) But it does mean that it's open to
> the community for feedback in the ways that have been described, in a way
> which is a clear improvement from the previous internal-only structure.

Here is a claim from a Karsten Wade that feels like a charade:

> "On the product/customer side, there was an openness gap—RHEL users (and consequently all rebuild users) couldn’t contribute easily to RHEL."

How exactly are we being empowered to "contribute easily to RHEL?"

Will Red Hat's new recognition of an openness gap mean we will finally get access to the kernel patches?  Or did Wade just say that because he thought it would sound good?  Is there any point in the community suggesting a SIG based around a better delivery system for kpatch?

Even if we aren't fully community controlled, how will the roadmap of Stream/RHEL be communicated?  Will Bex *EVER* introduce himself to the mailing list or do we get to guess what the roadmap is based on how packages are changing over time?

Will there be a community controlled Stream Plus packages?  Currently the "centosplus" directory but the Stream one continues to sit empty.  Will it someday silently just disappear?  Is there any point in purposing a BTRFS SIG to start populating Stream Plus?

When Red Hat employees post to the mailing list that we already have enough information to make a decision, does that indicate they have any interest in answering any of the above questions?!

> The original CentOS stream announcement used the term "midstream", which I
> like, but I also understand that introducing new terminology can create
> problems of its own. That announcement is also clear about the contribution
> model for Stream — transparent but ultimately Red Hat decisions.
> Characterizing further explanations of this as some kind of gotcha
> "admitting" isn't fair.
>
> As for BTRFS, I'm sure this has already been answered, but I'll say it
> again: Red Hat is definitely not at this time interested in BTRFS for RHEL,
> therefore unless Red Hat engineer and business minds are changed, that's not
> going to happen in CentOS Stream. However, a CentOS SIG which adds BTRFS
> would be very welcome.

The issue of BTRFS for RHEL was indirectly answered by the addition of Stratis in RHEL 8.  Red Hat put a lot of work into make XFS have the look/feel of BTRFS.

Also, when you say "very welcome" I think you mean Stream SIGs will still need a governance board sponsor to proceed.  Which of the governance board members has publicly expressed at any point in 2020 an  interest in making Stream SIGs feel very welcome in getting sponsored.

Maybe we can work with Mike McLean, Red Hat senior software engineer, about getting a BTRFS SIG added to the empty Stream Plus directory?  He introduced himself and gave a list of SIGs he is interested in sponsoring on the mailing list on ... well, never.

How about Brian Exelbierd?  Stream's roadmap is RHEL's roadmap.  Clearly interacting with the community should be important to him now? He publicly express interest in sponsoring a SIG... uh, never.

Or should we go to Jim Perrin at Microsoft??  Is he even still on the governance board?  Is the list even kept up to date on who to ask to get a sponsor for a SIG?

How about you, Matthew Miller?  Can we go to you to get Stream SIG sponsorship?  Are you even on the governance board for Stream?  Do you have any personal investment in making us "very welcome" to form a BTRFS SIG?

Should I continue down the list?

There is a reason why Stream Plus directory is empty.  We might find someone that pretends to express interest and asks us to do the work to make the packages only to then indicate there was no promise they would be the ones to sponsor.

Maybe it is unfair for us to toss around the word "charade" or maybe that is the hard reality?

> And, honestly, putting my Fedora hat back on, this makes perfect sense. We
> already have the Fedora Project. We don't need a second, overlapping one.
> If you want to work directly on operating system design, come join us over
> in Fedora. If you want to help guide Red Hat's decisions for RHEL minor
> releases, if you want early access to that development, if you want to build
> alternate ideas on that base, you're already in the right place.

Yes, we have a RHEL Insider Fast Ring called the Fedora Project.

What would make perfect sense is to make the RHEL Insider Slow Ring called Stream fall under Fedora Project as well.

If the CentOS community needs to pull their own weight to keep CentOS 8 going beyond 2021, then they should just say so.

Having Karsten Wade say that the vote back on November 11th was about Red Hat wanting to work with the community by forcing the termination of CentOS 8 is insulting.  They demostrated a desire to work with the community by waiting nearly a month to announce the change?

What SIG I want to work on is keeping CentOS 8 going without Red Hat employees having to do the work.  How "very welcome" will that SIG purposal go?

Instead of giving the community options, Wade makes the false claim that there exist a document which shows Stream can cover 95% of user workloads.  Stef Walter's document on "Stream is Continuous Delivery" is extremely well written and makes me excited about Stream.  (At this point it may sounds like I am being sarcastic, but I'm not.  I really think Stef Walter did a wonderful job.  I wish he was on the governance board.)  But Walter never says anything about 95% user workloads.  Wade is misrepresenting what Walter's blog post is about.

I honestly don't know if the word charade is being thrown around unfairly or not.  I do know if someone ask me to defend Red Hat's recent actions, I wouldn't know how to "sell" this.  I do feel confident that the 2014 merger assurances have panned out to be a charade.  Maybe only time can tell if this is another charade or not.