[CentOS-devel] Documenting the CentOS Linux 8 EOL process

Neal Gompa

ngompa13 at gmail.com
Fri Jul 16 07:43:51 UTC 2021


On Thu, Jul 15, 2021 at 7:25 PM Nico Kadel-Garcia <nkadel at gmail.com> wrote:
>
> On Thu, Jul 15, 2021 at 4:36 PM Johnny Hughes <johnny at centos.org> wrote:
>
> > Other than the kernels, I'm sorry but you would be hard pressed to find
> > something in Stream that doesn't also happen in CentOS and even RHEL.
> > It just happens a month or two earlier in Stream.  BUT, so do bugfixes :)
>
> I hope you understand that we expect both gross and subtle failures of
> the beta testing in CentOS 8 Stream. I expect it with python modules,
> when the author of one module fails to restrict versions of other
> modules, especially modules brought in by dependencies, to versions
> that are compatible because they cannot *predict* that the next
> version will be compatible. It can be very difficult to anticipate
> those: ansible is a great example right now, since the latest ansible
> release requires python 3.8 and the panoply of necessary modules are
> not yet available anywhere.
>

I hope you understand that we've actually taken care to deal with
issues like that. The CentOS/RHEL platform inherits all the work the
Fedora Python team and myself have done over the years to simplify,
automate, and rationalize Python packaging. The Python dependency
generator *already* deals with most of those problems for us. The
modularity tooling makes it relatively trivial for us to rebootstrap
the world of Python modules for a new Python version if we so choose.
Now, Red Hat has not currently elected to do this, but that doesn't mean it
isn't possible.

> It's one of the dangers of the "streaming" model, when unanticipated
> dependencies are discovered in the field.  It's why I expect people to
> use rsync or reposync tools to generate internal mirrors with locked
> snapshots, which they used to do with CentOS point releases.

You mean like how people *already* did it because they thought regular
CentOS updates were "too dangerous"? Frankly, I don't buy what you're
selling here. To make matters worse, the previous model gave you
*zero* opportunity to resolve issues with updates if they were buggy.
They just stayed broken for months or years. At least now there's a
chance of them getting fixed in a reasonable time window.

Nico, you spend far too much time looking at CentOS Stream the wrong
way. You should be looking at this as an opportunity to bring value to
the folks you work with leveraging the CentOS platform and to the
CentOS ecosystem as a whole. You can validate things early and often,
identify specific issues, contribute fixes, and be part of the process
to raise the quality bar for Enterprise Linux as a whole. And that's
the bare minimum! You could also go so much further if you wanted by
developing features that are useful to you and your organization in
Fedora and bringing them to RHEL/CentOS through the RHEL Feature
Proposal process handled by the CentOS Stream Feature SIG[1]. This
allows folks in the CentOS community to lobby for improvements in the
platform in an avenue that was never available to them before as
non-customers.

The whole point of CentOS Stream is continuous improvement. In a very
real way, CentOS Stream allows CentOS to truly earn its name as the
"Community Enterprise Operating System". We, the community, now have
the power to contribute, develop, and deliver *the* community
enterprise Linux platform. We've never had that before. We are the
folks with the opportunity to literally *set the standard* for
Enterprise Linux. Don't waste it!

And I'm putting my money where my mouth is. I've been actively
contributing to the platform since it launched. Even before this whole
self-inflicted disaster happened, I had already switched my CentOS
machines to CentOS Stream. I've been working in the Hyperscale SIG[2]
to develop features that I hope will be part of RHEL one day. And I'm
already looking forward to CentOS Stream 9.

[1]: https://wiki.centos.org/SpecialInterestGroup/StreamFeatureRequest
[2]: https://wiki.centos.org/SpecialInterestGroup/Hyperscale



--
真実はいつも一つ!/ Always, there's only one truth!


More information about the CentOS-devel mailing list