> On Jun 22, 2023, at 2:01 AM, Matthew Miller <mat...@fedoraproject.org> wrote: >> >>> >>> 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.
This was one of our key reasons to look at Fedora as an explicit upstream for the next generation of Amazon Linux. Without a feedback loop for contributions and changes, it severely limits what you may even want to incorporate, as merging this all for the next major release could be a major pain. Even trivially small things (such as bug fixes) that are beneficial to all (a random semi-recent example is making `lshw` not do a DNS lookup) weren’t *really* possible to quickly throw a pull request up for before CentOS Streams. There were other really nice properties of Fedora as well, such as each release having a mass-rebuild and thus you can be fairly sure that at any branch point, everything is quite likely to all build together. > 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. Maintaining git history is certainly fantastic from a transparency point of view. Beyond just git trees, we have had a few discussions in the Amazon Linux space on what we do with changelogs in the RPMs as well, especially with the increasing move to rpm-autospec, which means that git-merge of our own trees/rebuilds ends up with the old trick of “Release matches upstream, so it’s easy for humans” no longer that useful. There’s some balance of: - respect and refer to the amazing work done in the Fedora community - Don’t give Amazon Linux users the false impression that $random_fedora_contributor is who made the change in Amazon Linux that broke their $thing - that’s not fun for anybody. - Be clear as to the changes occurring in an Amazon Linux package update right now, for AL2023, We have an rpm-autospec-like thing at build time that will merge an `amzn-changelog` file that’s present in the git repo with the ‘%changelog’ in the SPEC file on SRPM build. The aim here is to be able to add changelog entries that are amzn specific easily, while not creating merge conflicts all the time It’d be great if we ended up with CentOS Stream and Amazon Linux doing the same thing, if only for consistency and being able to set some good expectation / good practice for distros downstream from Fedora. Maybe it’s a question for Fedora developers: how do you *want* downstream distributions to behave in this area? There’s guidelines for https://fedoraproject.org/wiki/Remix and https://fedoraproject.org/wiki/Spins_SIG along with https://fedoraproject.org/wiki/Releases/FeatureGenericLogos making some parts of downstream distros easier to do. > 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: This reminds me of the item on my TODO list of to start a discussion around how we can better have distro and package level option switches that both Fedora and downstream distros can flip on and off over time. I’ll go do that now... > 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 It’s also a good place to collaborate on some of the common base components of a Fedora based distro that has a longer support life cycle than a Fedora release gets. This may be a more significant part of the Amazon Linux story as AL2023 and beyond ages, as well as we tune how we interact with upstreams with bug fixes in an existing OS version. > > > 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.) If I was going to put a diagram of where Amazon Linux sits in that ecosystem, it’d likely look something like this: Fedora ——> Amazon Linux \____> CentOS Stream —> RHEL _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
