"technical steering committee" for a project that does no engineering of their own

Posted Nov 4, 2023 16:01 UTC (Sat) by jzb (editor, #7867)
In reply to: "technical steering committee" for a project that does no engineering of their own by pizza
Parent article: OpenELA's first code drop

It's unclear from public statements whether the OpenELA folks intend to diverge from RHEL or not. As a spectator, I would love to see them attempt to establish a community EL that they drive and compete with RHEL as a standard.

I feel like that would be more honest and actual competition, rather than leaving it to Red Hat to do all the work up to releasing the code and then rushing behind them to compile it and undercut Red Hat on pricing and little else.

IMO, it's not particularly good for the larger industry/ecosystem to undercut Red Hat's revenue and ability to develop software while not picking up the slack. If SUSE, Oracle, and CIQ are out there hiring all the folks who support the types of work Red Hat is doing (not only coding, but testing, product management, etc.) then great. If they're just siphoning the code and then making it harder for Red Hat to pay for the work that goes into RHEL... not so good.

"technical steering committee" for a project that does no engineering of their own

Posted Nov 6, 2023 11:18 UTC (Mon) by rolexhamster (guest, #158445) [Link] (13 responses)

I would love to see them attempt to establish a community EL that they drive and compete with RHEL as a standard.

There are already 2 community "EL" distros that compete with RHEL: (1) Debian LTS and (2) Ubuntu LTS, both of which ship a ton of code developed and/or checked by Red Hat (i.e. indirectly paid for by subscriptions to RHEL).

Debian LTS info and EOL dates
Ubuntu LTS EOL dates

It can also be argued that CentOS Stream is a competitor of sorts to RHEL as well. Even though Red Hat killed the original CentOS project, OpenELA can and will use CentOS Stream sources against Red Hat.

CentOS Stream is ostensibly meant as an intermediary between Fedora and RHEL, as part of the pipeline for developing and stabilizing RHEL releases (major and minor). Unless OpenELA steps up and actually contributes something of meaningful value to CentOS Stream, I can't see how the current status quo with CentOS Stream will continue.

CentOS Stream has no value to Red Hat unless RH gets something out of it (say, at the very least, bug reports). To a large extent, Fedora already serves as a decent testing ground for RHEL. Red Hat (or IBM) execs will either withdraw support from CentOS Stream, or (most likely) change it to an internal Red Hat project, absorbing it into the internal RHEL development process. Only Fedora would remain as the publicly available upstream to RHEL.

"technical steering committee" for a project that does no engineering of their own

Posted Nov 6, 2023 11:34 UTC (Mon) by farnz (subscriber, #17727) [Link] (2 responses)

I'd just note that CentOS Stream used to be an internal Red Hat project as part of the internal RHEL development process, and not something that was publicly exposed. Reversing that decision would cost Red Hat a lot more goodwill than cracking down on bug-for-bug clones of RHEL has done, since many consumers of CentOS Stream are people who transitioned away from bug-for-bug clones and who now contribute by providing useful bugs reports and/or code to CentOS Stream.

"technical steering committee" for a project that does no engineering of their own

Posted Nov 6, 2023 11:45 UTC (Mon) by rolexhamster (guest, #158445) [Link] (1 responses)

<ul>
<i>
... many consumers of CentOS Stream are people who transitioned away from bug-for-bug clones and who now contribute by providing useful bugs reports and/or code to CentOS Stream.
</i>
</ul>
Is there actually evidence of this, and are these bug reports making a meaningful difference? (Genuine question -- I haven't checked CentOS Stream bug reports). If indeed it's true, CentOS Stream would be providing value to Red Hat, which would hopefully offset the damage caused by OpenELA.

"technical steering committee" for a project that does no engineering of their own

Posted Nov 6, 2023 14:08 UTC (Mon) by farnz (subscriber, #17727) [Link]

Yes - I see contributions to CentOS Stream and to ELN (the upstream of CentOS Stream) coming from my former employer, and I've never worked for Red Hat. From what I can tell from the outside, these are genuinely useful contributions, too, not just "foo doesn't work" type of reports.

"technical steering committee" for a project that does no engineering of their own

Posted Nov 6, 2023 14:02 UTC (Mon) by pizza (subscriber, #46) [Link]

> CentOS Stream is ostensibly meant as an intermediary between Fedora and RHEL, as part of the pipeline for developing and stabilizing RHEL releases (major and minor)

Not quite. "EL Next" (ELN) is the intermediate step between Fedora and RHEL. CentOS Stream is a rolling release distro of what will the next RHEL point release, with each update going through RH's full QA pipeline.

ELN (public) -> Stream boostrap (internal) -> Stream + RHEL .0 release (public)

After the .0 release, subsequent .X releases are snapshotted/branched from the current state of Stream.

"technical steering committee" for a project that does no engineering of their own

Posted Nov 6, 2023 15:04 UTC (Mon) by jhoblitt (subscriber, #77733) [Link] (2 responses)

I would not characterize Ubuntu as a community distribution. How many non-canonical employees decide the direction of the distro, what is packaged in each release, and perform QA?

"technical steering committee" for a project that does no engineering of their own

Posted Nov 6, 2023 15:11 UTC (Mon) by jhoblitt (subscriber, #77733) [Link]

I also would not consider centos steam a community project as it completely controlled by a for-profit enterprise. Fedora is kind of a hybrid in that several key positions are appointed by (and employees of) RedHat but there is significant technical decisions making driven by project members external to RedHat.

"technical steering committee" for a project that does no engineering of their own

Posted Nov 7, 2023 11:35 UTC (Tue) by rolexhamster (guest, #158445) [Link]

I would not characterize Ubuntu as a community distribution. How many non-canonical employees decide the direction of the distro, what is packaged in each release, and perform QA?

Each Ubuntu release is essentially a snapshot of Debian unstable at a particular point of time. Ubuntu may add a bit of sprinkling here and there, but much (if not the majority) of the direction setting and QA has already been "done" at the snapshot stage (via Debian processes and policies) by volunteers and organizations supporting Debian.

The additional QA for Ubuntu LTS releases is also mainly done by volunteers (i.e. the users). When LTS version (N).04.0 is released, users of LTS version (N-1).04.x are not automatically prompted to upgrade. Instead, Canonical waits until "enough" bugs have been reported and shaken out, then releases LTS version (N).04.1, and then finally allows upgrades from version (N-1).04.x. In other words, each Ubuntu (N).04.0 LTS release is in fact a public beta release, all while Canonical pretends it's not.

"technical steering committee" for a project that does no engineering of their own

Posted Nov 7, 2023 3:34 UTC (Tue) by calumapplepie (guest, #143655) [Link] (5 responses)

> There are already 2 community "EL" distros that compete with RHEL: (1) Debian LTS and (2) Ubuntu LTS, both of which ship a ton of code developed and/or checked by Red Hat (i.e. indirectly paid for by subscriptions to RHEL).

I disagree with the implication that Ubuntu and Debian are Red Hat supported. Yes, Red Hat spends a ton of time and money on LTS for software. So does Canonical. So do Debian developers. Determining who spends the most would be really hard; Debian devs support obscure architectures that nobody else does, Canonical is a whole blown competitor to Red Hat, etc. Implying that either of those would not exist were it not for Red Hat is a bit silly.

"technical steering committee" for a project that does no engineering of their own

Posted Nov 7, 2023 11:56 UTC (Tue) by rolexhamster (guest, #158445) [Link] (4 responses)

I disagree with the implication that Ubuntu and Debian are Red Hat supported (...) Implying that either of those would not exist were it not for Red Hat is a bit silly.

Eh? No such implication was made. In the hypothetical scenario where Red Hat never existed, Debian and Ubuntu may still exist, but would almost certainly not be as good as they are now.

Debian and Ubuntu contain a truckload of software developed and/or checked by Red Hat, simply by the virtue of Red Hat widely participating in the open source / free software ecosystem (e.g. via Fedora and upstream contributions to many projects). Red Hat's participation is paid for by RHEL subscriptions (support contracts).

"technical steering committee" for a project that does no engineering of their own

Posted Nov 7, 2023 18:21 UTC (Tue) by amacater (subscriber, #790) [Link] (3 responses)

It also works the other way round - Red Hat probably wouldn't have run on anything other than i386 / amd64 were it not for Debian bootstrapping 32 bit and 64 bit ARM, for example, and Debian still
maintains ports for other machine types.

Debian is also the upstream for several projects. Numbers of packages is not necessarily a metric
but the Debian package universe comfortably dwarfs RHEL and EPEL together, I think.

[Full disclosure: I'm a Debian developer and have been a sysadmin for many years - there's a *reason*
my home machines and hosting all runs Debian :) ]

LWN no longer maintains the Distributions list but relative popularity of Debian-derived vs. Red Hat derived distributions is instructive.

"technical steering committee" for a project that does no engineering of their own

Posted Nov 7, 2023 20:24 UTC (Tue) by zdzichu (subscriber, #17118) [Link]

Really? I cannot recollect any Debian developer defining how aarch64 should look like. But I remember few Red Hat developers, Jon Masters being the most prominent one.

"technical steering committee" for a project that does no engineering of their own

Posted Nov 7, 2023 21:12 UTC (Tue) by Wol (subscriber, #4433) [Link] (1 responses)

> LWN no longer maintains the Distributions list but relative popularity of Debian-derived vs. Red Hat derived distributions is instructive.

And the ones that are neither ... ?

Slackware may not have the numbers, but it still has quite some mindshare. The Gentoo family ...

And of course there's SUSE which, while it now uses RPM, it predates Red Hat ...

Cheers,
Wol

"technical steering committee" for a project that does no engineering of their own

Posted Nov 7, 2023 21:39 UTC (Tue) by zdzichu (subscriber, #17118) [Link]

Gentoo and Arch derivatives (as ChromeOS and Steam Deck) seem to be more popular than any other s.

"technical steering committee" for a project that does no engineering of their own

Posted Nov 14, 2023 13:25 UTC (Tue) by durikmel (subscriber, #162032) [Link] (1 responses)

OpenELA intends to be providing both, but is focusing on bug for bug compatibilty at the moment. See https://github.com/openela/governance/blob/main/contribut... for details.

"technical steering committee" for a project that does no engineering of their own

Posted Nov 14, 2023 14:02 UTC (Tue) by pizza (subscriber, #46) [Link]

That document seems to more or less say three things:

1) Pull patches from upstream EL (ie RHEL or CentOS Stream).
2) When that's not possible, contribute changes to upstream first (ie CentOS Stream)
3) Anything that's not already upstream will be handled in a TBD manner.

...In other words, they only intend to accept changes already vetted by Red Hat QA. (So much to providing their own QA resources...)

That said, they also have a "-contrib" repository for ABI-incompatible modifications to upstream packages or packages that don't exist upstream in RHEL/CentOS already. It remains to be seen what this repo (and their governance therof) will offer that existing EL add-on repos (eg EPEL, RPMFusion, etc) do not. Also noteworthy is that there's zero promises made about ABI (or any other form of) stability for -contrib stuff.

Lots of high-minded rhetoric here, but in the end, it's still just a 1:1 rebuild of RHEL, and still lacks any concrete details on how they're going to handle updates between the five-year delta between the EOL of CentOS Stream X and RHEL X. (For free. Since that's the _only_ thing its prospective users actually care about...)