[CentOS-devel] Vote of Confidence

On Mon, Jan 4, 2021 at 2:54 AM redbaronbrowser via CentOS-devel
<centos-devel at centos.org> wrote:
> > 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.

I asked about BTRFS earlier and as far as I can tell, it was not
answered - at least not in this thread, or in the context of "CentOS
Stream" and what this new commitment to openness would do to change
the answer.

The reason I asked about BTRFS is because of this:

> 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.

Architecturally, Stratis seems to follow the Docker LVM / dm-thinp
storage driver, which was an interesting approach, but ultimately
ended up being deprecated as a poor model due to its emphasis on
correct file system isolation over practical concerns like shared file
system caching and performance. It means that it performs poorly at
scale, and I suspect the same thing will happen with Stratis. There
are too many compromises being made with Stratis, to re-use XFS for a
purpose that it wasn't really meant for. BTRFS will prove to be
better, having a much larger community to support it, and Stratis will
end up a Red Hat only project, that does not get broadly adopted. Even
if Stratis might be better - without the community, it will eventually
be too expensive to invest in given the limited returns. But, this
isn't a discussion about Stratis... I'm just giving some context of
what a reasonable community discussion *might* include...

The question is about how CentOS Stream can ensure this conversation
happens, and that the "community" (not just developers, but USERS...
you know, the people that the product is being designed to satisfy?)
can provide this feedback, and provide true influence on the direction
of RHEL. Right now, Red Hat is deciding to go with Stratis, and drop
BTRFS, in direct contrast to what the "community" wants to see. I
would argue right now, that one of the *best* reasons to use Oracle
Linux instead of CentOS or RHEL, is because Oracle supports BTRFS in
their distribution, and if you need BTRFS for an Enterprise Linux
distribution, you don't really have a choice any more. Red Hat opted
out.

> 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.

I don't understand why SIG requires CentOS Stream, and does not
require CentOS. Eventually, we're going to have a paradox to deal
with:

1) CentOS Stream is the only supported "free" EL distribution from Red Hat.
2) CentOS SIG will need to support all of: CentOS Stream, RHEL, and at
least one other - Rocky?

This paradox means that the SIG now have *more* work to do than
before. What about projects like RDO? Will they be publishing for
Fedora, CentOS Stream, and EL? Will they be able to do this long-term?
Or will they end up:

A) Dropping EL support, and focusing on CentOS Stream. Now, projects
like RDO only work on CentOS Stream, and don't work on RHEL? How will
this help RHEL?
B) Dropping CentOS Stream support, and only work on RHEL / Rocky? How
will this leverage CentOS Stream?

This is a mess about to happen. This mess is worse due to the people
who claim CentOS Stream is good enough for "95%" of all users. It will
lead to SIG specifically targeting CentOS Stream and only CentOS
Stream, and no guarantee that their product output will work on RHEL
or Rocky, since RHEL and Rocky will be older baselines that cannot be
easily or reliably built from a CentOS Stream source. Do the people
making the decisions realize this? Because, it leaves me in a state of
concern that either they do know this, and they are planning to
totally upset the ecosystem (without any consultation with the users
who are the most impacted), or they don't know this, and they are soon
to be surprised (leaving the users to scramble from one sinking ship
to another at their own peril).

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

Individual people are sincere. I believe Matthew is sincere.

However, sincerity doesn't really change the results. I am not
claiming anybody here is a bad person or is being less than completely
sincere. I am claiming that there are varied interests, and the people
with these interests are emphasizing the values that they see, and
downplaying the consequences that they are aware of, and the result is
basically the same thing. Willingly, or unwillingly, it is a charade -
"an absurd pretense intended to create a pleasant or respectable
appearance". In this case, Red Hat is killing CentOS as we know it
(including using their acquisition of the trademark to force it to
die), and selling this as a win for the "community" (= which doesn't
seem to include users?) everywhere, because instead of CentOS, an OS
distro that inherits the hardened nature of RHEL, you can now run
CentOS Stream as a preview of RHEL instead, upstream of RHEL, and it
will be good enough for "95% of users" (with no clear definition of
who these users are). This is the absurd pretense intended to create a
please or respectable appearance. Not everybody is making this absurd
pretense, but some still are. Or, perhaps, I just need a little
"faith"... it is a Cathedral, and I am basically speaking blasphemy.
:-)

> > 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.

RHEL minor releases introduce and deprecate functions. RHEL has
historically been around 10 years, and that is a long time in Internet
years. Docker was in its infancy in RHEL 7.0 time-frame, and thinks
like overlayfs were necessary backports to keep RHEL 7 relevant. This
is part of the definition of the "slow ring", and ability to
contribute to it means ability to influence what decisions get made,
despite having stronger requirements for stability from the users.
Fedora moves too quickly, and doesn't have a point release. It can be
used for production purposes (I've done it before), but it comes at a
cost that shouldn't be taken lightly, similarly but to a lesser
degree, why CentOS Stream in production use cases would come at a cost
that should not be taken lightly. You basically have to be prepared
for your systems to break at any time, and have your own testing and
stabilization processes in place, to prevent this from happening. Some
of us can do this - most of us cannot. And, even for those that can do
it - we want to use it sparingly, only where it matters the most. Not
everything has to be new all the time, despite what easily excitable
developers will push for. We need both an upstream and a downstream to
have an effective community. CentOS Stream is not a downstream - it is
neither downstream of Fedora, nor downstream of RHEL. CentOS Stream is
a branch of RHEL (and RHEL is a branch of Fedora) that runs ahead of
RHEL, and acts as a more effective beta program for RHEL. I would love
to have a more effective beta program for RHEL, but this is not a
replacement for CentOS.

Also on the comment of "come join us over in Fedora", I do. Fedora is
a very important project that goes beyond RHEL. I'm one of your many
"users" who you co-opt as developers according to the Bazaar vs
Cathedral models, by doing a lot of the hard work of diagnosing
problems and raising them to the attention of people who can fix them,
including patches when I am able to. But, companies don't run on just
one thing. I work with and on Fedora, so that 2 to 5 years from now,
it will be available in EL. It is a long-term investment. The same
would apply to CentOS Stream, and the same applies to CentOS. All of
these are necessary components. Without CentOS, I don't see how SIG
can confirm their products will work on EL - whether RHEL, or Rocky,
or Oracle Linux. Possibly, Red Hat will make RHEL free for this
limited use case, and effectively constrain the size of the community
to either those who pay nearly full list price for RHEL for all
systems (as is required today), or special licenses that are
encumbered, that might allow a limited amount of "free" usage, but is
almost too hard to obtain in the first place, so most people don't
bother.

-- 
Mark Mielke <mark.mielke at gmail.com>