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!