>> ELN is a build of (some) Fedora packages with EL-specific options, so >> it requires Fedora. > ELN can exist off an internal non fedora tree. Just depends who is > updating the tree. Sure, but... that's the _opposite_ of the direction things are going. Previously, what happened to make a major RHEL release was: 1. Some Fedora Linux Release -> an internal bootstrap 2. ... a year or so of secret work ... 3. RHEL Beta 4. RHEL Release 5. CentOS Linux rebuild 6. Internal RHEL build process, internal work on minor release 7. RHEL updates appear in publiuc 8. CentOS Linux rebuilds of those. There's no connection to Fedora beyond the intial fork, and a lot of work done inside Red Hat without any transparency. Now, CentOS Stream brings that to the surface: 1. Fedora Rawhide continually updated 2. ELN maintained in parallel, as part of Fedora 3. At some point, ELN branched to new CentOS Stream 4. ... a year or so of CentOS Stream development in public ... 5. RHEL Beta forked from that, released 6. Work on RHEL updates visible in CentOS Stream 7. Updates appear in CentOS Stream 8. Updates released to RHEL Note that with CentOS Stream 10 / RHEL 10, step 3 here will _maintain git history from Fedora, which is a big improvement in preserving all of the incredible, valuable work from Fedora contributors. All of this is the exact opposite of Red Hat preparing to make some new base for RHEL. Additionally, this model provides a clean path for Red-Hat-opinionated decisions to differ from those we make from Fedora. Take BTRFS as an example. Or, the increase in CPU baseline. Like this: Fedora Linux: Community Space ----------------------------- * Community engineering decisions * No special code privileges due to your employer * Community-run infrastructure with RH investment, significant resources from Amazon, contributions from other companies * Community quality engineering with RH investment * Community support * No cost CentOS Stream: Shared Space --------------------------- * Red Hat Engineering decisions with community input * Pull requests from the community, approval from Red Hat engineers * Red Hat-provided and maintained infrastructure * Red Hat quality engineering with partner and community involvement * Community support * no cost Red Hat Enterprise Linux: Product Space --------------------------------------- * Red Hat Engineering decisions with customer input * Red Hat engineers and only RH engineers do the work * Red Hat infrastructure * Red Hat quality engineering (mostly done in Stream, though) * Enterprise support * Subscription, including low- and no-cost options Previously, we had a whole convoluted thing which people tried to describe in terms of MC Escher paintings. This is far better, and Fedora is in a better place. In the earlier setup, CentOS _was_ sometimes positioned as a competitor (although generally, those of us working in the actual Fedora and CentOS communities didn't have any interest in playing that game.) -- Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> Fedora Project Leader _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
