On Jun 22, 2023, at 2:01 AM, Matthew Miller
>> 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
- 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
making some parts of
downstream distros easier to do.
All of this is the exact opposite of Red Hat preparing to make some
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