Hi all,
Last November, Red Hat announced Project Hummingbird [1], a catalog of minimal, hardened container images designed to accelerate application development with a minimal CVE strategy. The images include the latest languages and runtimes (Node, Go, .NET, Java, Python, Rust, Ruby), developer databases (PostgreSQL, MariaDB), web servers and proxies (Nginx, Caddy, HAProxy), and other foundational components for modern application stacks [3].
What's interesting for Fedora: Project Hummingbird is built using the open source development process, originating from Fedora Linux components (some Rawhide, some Stable). The press release notes that unsupported images are freely available and redistributable, following a similar model to Red Hat Universal Base Image (UBI) [5]. The work is already happening in the open [2] with images available [3].
We'd like to explore bringing this work more formally into the Fedora community and creating a space where this innovation can continue in the open. This would follow similar patterns we've seen with other successful incubation efforts in Fedora like ELN [4].
Before we go down the formal Change Proposal path, I wanted to gauge community interest and see if there's appetite for this kind of project.
Thoughts?
P.S. I'm heading on PTO tomorrow April 23rd, but I'll be back on Monday, April 27th. I commit to reading and responding to any messages when I return.
Kind Regards Scott McCarty
References: [1] https://www.redhat.com/en/about/press-releases/red-hat-introduces-project-hu... [2] https://gitlab.com/redhat/hummingbird/containers [3] https://quay.io/organization/hummingbird [4] https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose [5]: https://www.redhat.com/en/blog/introducing-red-hat-universal-base-image
Hey Scott,
On Thu, Apr 23, 2026, at 4:19 AM, Scott McCarty wrote:
What's interesting for Fedora: Project Hummingbird is built using the open source development process, originating from Fedora Linux components (some Rawhide, some Stable).
Can you share some more in how Project Hummingbird does this? From a cursory look through [1] it seems like it takes the rawhide spec files, (potentially) patches them, builds them; after which it puts them into a container?
We'd like to explore bringing this work more formally into the Fedora community and creating a space where this innovation can continue in the open. This would follow similar patterns we've seen with other successful incubation efforts in Fedora like ELN [4].
A bit more specific, are you proposing a separate buildroot for RPMs (like ELN)? Do you want to start building your RPMs in Koji; or will you continue to build these RPMs and containers in Konflux (I assume so)?
Before we go down the formal Change Proposal path, I wanted to gauge community interest and see if there's appetite for this kind of project.
So far it sounds like you'll be rebuilding the RPMs from rawhide (or other branches) in Konflux and turning those into containers.
To *me* that sounds like Project Hummingbird could be a SIG that asks for co-maintainership of the packages you're currently rebuilding and thus contribute patches, updates, and assorted other bits and bobs in rawhide (or other branches) which clearly benefits all of Fedora (more updates! faster! better?).
You'd then be building those RPMs in Project Hummingbirds' Konflux together with your containers without going through Bodhi so you can keep your 'very quick updates/zero-CVEs' path especially for stable branches
Thoughts?
All-in-all it'd be great to have more contributors to these much used packages in Fedora but I'm assuming here that what I described above is accurate. I think a packaging SIG would be sufficient which wouldn't require a change proposal.
P.S. I'm heading on PTO tomorrow April 23rd, but I'll be back on Monday, April 27th. I commit to reading and responding to any messages when I return.
Enjoy :)
On Thu, 2026-04-23 at 07:18 +0200, Simon de Vlieger wrote:
Hey Scott,
On Thu, Apr 23, 2026, at 4:19 AM, Scott McCarty wrote:
What's interesting for Fedora: Project Hummingbird is built using the open source development process, originating from Fedora Linux components (some Rawhide, some Stable).
Can you share some more in how Project Hummingbird does this? From a cursory look through [1] it seems like it takes the rawhide spec files, (potentially) patches them, builds them; after which it puts them into a container?
We'd like to explore bringing this work more formally into the Fedora community and creating a space where this innovation can continue in the open. This would follow similar patterns we've seen with other successful incubation efforts in Fedora like ELN [4].
A bit more specific, are you proposing a separate buildroot for RPMs (like ELN)? Do you want to start building your RPMs in Koji; or will you continue to build these RPMs and containers in Konflux (I assume so)?
Before we go down the formal Change Proposal path, I wanted to gauge community interest and see if there's appetite for this kind of project.
So far it sounds like you'll be rebuilding the RPMs from rawhide (or other branches) in Konflux and turning those into containers.
To *me* that sounds like Project Hummingbird could be a SIG that asks for co-maintainership of the packages you're currently rebuilding and thus contribute patches, updates, and assorted other bits and bobs in rawhide (or other branches) which clearly benefits all of Fedora (more updates! faster! better?).
You'd then be building those RPMs in Project Hummingbirds' Konflux together with your containers without going through Bodhi so you can keep your 'very quick updates/zero-CVEs' path especially for stable branches
Thoughts?
All-in-all it'd be great to have more contributors to these much used packages in Fedora but I'm assuming here that what I described above is accurate. I think a packaging SIG would be sufficient which wouldn't require a change proposal.
Well, if we're going to brand the deliverables (containers) as "Fedora", that kinda needs to go through the sausage factory at least a bit, I think. From the PoV that it won't likely cause issues for all the other existing build processes and deliverables it doesn't really need much oversight, but from the PoV that it's potentially a new set of things we're putting the Fedora name on, it kinda does. Depending on how prominent we want to make it, about as much as a new spin would need, or a new Edition?
On Thu, Apr 23, 2026, at 7:58 AM, Adam Williamson wrote:
Well, if we're going to brand the deliverables (containers) as "Fedora", that kinda needs to go through the sausage factory at least a bit, I think. From the PoV that it won't likely cause issues for all the other existing build processes and deliverables it doesn't really need much oversight, but from the PoV that it's potentially a new set of things we're putting the Fedora name on, it kinda does. Depending on how prominent we want to make it, about as much as a new spin would need, or a new Edition?
Right yes, if the intent is to become "Fedora Hummingbird" or such then a change proposal is necessary. It isn't entirely clear here if that's the direction (for me).
Simon and Adam, The plan is to bring this work into Fedora under the Fedora Innovation Lifecycle proposal [1]. That would allow us to still build it in the Red Hat infrastructure (for now), while we figure out how to mature it (both for Fedora infrastructure, as well as how users use it). And, like you both mention, this will give us time to mature it, potentially into a Remix or Edition, etc. But, I want to stress that we're committed to doing this in a community-driven way.
[1]: https://fedoraproject.org/wiki/User:Jspaleta/Drafts/FedoraInnovationLifecycl...
On Tue, 2026-04-28 at 00:35 +0000, Scott McCarty wrote:
Simon and Adam, The plan is to bring this work into Fedora under the Fedora Innovation Lifecycle proposal [1]. That would allow us to still build it in the Red Hat infrastructure (for now), while we figure out how to mature it (both for Fedora infrastructure, as well as how users use it). And, like you both mention, this will give us time to mature it, potentially into a Remix or Edition, etc. But, I want to stress that we're committed to doing this in a community-driven way.
Thanks, Scott. Assuming "it" (for whichever value of "it" we're thinking of at a given moment...) is built with Konflux, I think it'd be ideal if at all possible to prioritize trying to build "it" in Fedora Konflux ASAP. Currently, AFAIK, CoreOS is the most active "client" trying to move its production build process to Konflux: https://github.com/coreos/fedora-coreos-tracker/issues/2125 . IoT has some tickets from last year indicating an effort along those lines - https://github.com/fedora-iot/iot-distro/issues/53 , https://github.com/fedora-iot/iot-distro/issues/99 - but they seem to have stagnated.
Per https://redhat.atlassian.net/browse/KONFLUX-11098 , the new production Fedora Konflux is deployed...somewhere?...as of April 21, so that's something to work with.
On 23. 04. 26 7:58, Adam Williamson wrote:
All-in-all it'd be great to have more contributors to these much used packages in Fedora but I'm assuming here that what I described above is accurate. I think a packaging SIG would be sufficient which wouldn't require a change proposal.
Well, if we're going to brand the deliverables (containers) as "Fedora", that kinda needs to go through the sausage factory at least a bit, I think. From the PoV that it won't likely cause issues for all the other existing build processes and deliverables it doesn't really need much oversight, but from the PoV that it's potentially a new set of things we're putting the Fedora name on, it kinda does. Depending on how prominent we want to make it, about as much as a new spin would need, or a new Edition?
(Disclaimer: But my reply is my own summary of how I grasped this after talking to Scott several times about this topic.)
I believe the main idea now is to have Hummingbird part of the Fedora Project, have a SIG and a place to do things (e.g. in Fedora Forge, Fedora Matrix, etc.). The specific results/deliverables and impact on Fedora Linux would be determined later. Perhaps it would be a spin, perhaps an edition, perhaps something new. When that happens, I am sure it will be done via a Change proposal or a Fedora Initiative er other appropriate means.
I said this to Scott already but let me say it in a public mailing list as well: I believe having projects like this in the Fedora space makes perfect sense wrt our mission[1]:
""" Fedora creates an innovative platform for hardware, clouds, and containers that enables software developers and community members to build tailored solutions for their users. """
And as such, I wholeheartedly support this idea. That does not mean I won't be scrutinizing any technical proposals when hey happen :D
[1] https://docs.fedoraproject.org/en-US/project/#_our_mission
On 4/23/26 7:33 AM, Miro Hrončok wrote:
On 23. 04. 26 7:58, Adam Williamson wrote:
All-in-all it'd be great to have more contributors to these much used packages in Fedora but I'm assuming here that what I described above is accurate. I think a packaging SIG would be sufficient which wouldn't require a change proposal.
Well, if we're going to brand the deliverables (containers) as "Fedora", that kinda needs to go through the sausage factory at least a bit, I think. From the PoV that it won't likely cause issues for all the other existing build processes and deliverables it doesn't really need much oversight, but from the PoV that it's potentially a new set of things we're putting the Fedora name on, it kinda does. Depending on how prominent we want to make it, about as much as a new spin would need, or a new Edition?
(Disclaimer: But my reply is my own summary of how I grasped this after talking to Scott several times about this topic.)
I believe the main idea now is to have Hummingbird part of the Fedora Project, have a SIG and a place to do things (e.g. in Fedora Forge, Fedora Matrix, etc.). The specific results/deliverables and impact on Fedora Linux would be determined later. Perhaps it would be a spin, perhaps an edition, perhaps something new. When that happens, I am sure it will be done via a Change proposal or a Fedora Initiative er other appropriate means.
I said this to Scott already but let me say it in a public mailing list as well: I believe having projects like this in the Fedora space makes perfect sense wrt our mission[1]:
""" Fedora creates an innovative platform for hardware, clouds, and containers that enables software developers and community members to build tailored solutions for their users. """
And as such, I wholeheartedly support this idea. That does not mean I won't be scrutinizing any technical proposals when hey happen :D
[1] https://docs.fedoraproject.org/en-US/project/#_our_mission
I think this is a great idea to be made part of Fedora.
On Thu, 2026-04-23 at 13:33 +0200, Miro Hrončok wrote:
On 23. 04. 26 7:58, Adam Williamson wrote:
All-in-all it'd be great to have more contributors to these much used packages in Fedora but I'm assuming here that what I described above is accurate. I think a packaging SIG would be sufficient which wouldn't require a change proposal.
Well, if we're going to brand the deliverables (containers) as "Fedora", that kinda needs to go through the sausage factory at least a bit, I think. From the PoV that it won't likely cause issues for all the other existing build processes and deliverables it doesn't really need much oversight, but from the PoV that it's potentially a new set of things we're putting the Fedora name on, it kinda does. Depending on how prominent we want to make it, about as much as a new spin would need, or a new Edition?
(Disclaimer: But my reply is my own summary of how I grasped this after talking to Scott several times about this topic.)
I believe the main idea now is to have Hummingbird part of the Fedora Project, have a SIG and a place to do things (e.g. in Fedora Forge, Fedora Matrix, etc.). The specific results/deliverables and impact on Fedora Linux would be determined later. Perhaps it would be a spin, perhaps an edition, perhaps something new. When that happens, I am sure it will be done via a Change proposal or a Fedora Initiative er other appropriate means.
Oh, for that kinda thing I'd agree it probably doesn't even need a Change.
I can't find a doc for forming a WG (I *think* WGs can only be designated by FESCo / Council maybe?), but we have a doc for forming a SIG and it's basically self-service:
https://fedoraproject.org/wiki/Creating_a_Fedora_SIG
you just say you're a SIG, file a few tickets to ask for whatever Forge org, chat room, Discourse tag etc. you want, and...you're a SIG! I think that's totally fine for the above.
On Thu, Apr 23, 2026 at 8:17 AM Adam Williamson adamwill@fedoraproject.org wrote:
On Thu, 2026-04-23 at 13:33 +0200, Miro Hrončok wrote:
On 23. 04. 26 7:58, Adam Williamson wrote:
All-in-all it'd be great to have more contributors to these much used packages in Fedora but I'm assuming here that what I described above is accurate. I think a packaging SIG would be sufficient which wouldn't require a change proposal.
Well, if we're going to brand the deliverables (containers) as "Fedora", that kinda needs to go through the sausage factory at least a bit, I think. From the PoV that it won't likely cause issues for all the other existing build processes and deliverables it doesn't really need much oversight, but from the PoV that it's potentially a new set of things we're putting the Fedora name on, it kinda does. Depending on how prominent we want to make it, about as much as a new spin would need, or a new Edition?
(Disclaimer: But my reply is my own summary of how I grasped this after talking to Scott several times about this topic.)
I believe the main idea now is to have Hummingbird part of the Fedora Project, have a SIG and a place to do things (e.g. in Fedora Forge, Fedora Matrix, etc.). The specific results/deliverables and impact on Fedora Linux would be determined later. Perhaps it would be a spin, perhaps an edition, perhaps something new. When that happens, I am sure it will be done via a Change proposal or a Fedora Initiative er other appropriate means.
Oh, for that kinda thing I'd agree it probably doesn't even need a Change.
I can't find a doc for forming a WG (I *think* WGs can only be designated by FESCo / Council maybe?), but we have a doc for forming a SIG and it's basically self-service:
WGs are created through the Council. The last WG created was the PSWG for the KDE Plasma Desktop Edition.
https://fedoraproject.org/wiki/Creating_a_Fedora_SIG
you just say you're a SIG, file a few tickets to ask for whatever Forge org, chat room, Discourse tag etc. you want, and...you're a SIG! I think that's totally fine for the above.
A SIG is probably sufficient for now, WGs are only required for Editions. But starting out as an Edition is unnecessary and probably not a good idea. Building out as a spin deliverable and once critical mass has been reached, the WG/Edition conversation can happen later.
-- 真実はいつも一つ！/ Always, there's only one truth!
On 23/04/2026 17.17, Adam Williamson wrote:
On Thu, 2026-04-23 at 13:33 +0200, Miro Hrončok wrote:
On 23. 04. 26 7:58, Adam Williamson wrote:
All-in-all it'd be great to have more contributors to these much used packages in Fedora but I'm assuming here that what I described above is accurate. I think a packaging SIG would be sufficient which wouldn't require a change proposal.
Well, if we're going to brand the deliverables (containers) as "Fedora", that kinda needs to go through the sausage factory at least a bit, I think. From the PoV that it won't likely cause issues for all the other existing build processes and deliverables it doesn't really need much oversight, but from the PoV that it's potentially a new set of things we're putting the Fedora name on, it kinda does. Depending on how prominent we want to make it, about as much as a new spin would need, or a new Edition?
(Disclaimer: But my reply is my own summary of how I grasped this after talking to Scott several times about this topic.)
I believe the main idea now is to have Hummingbird part of the Fedora Project, have a SIG and a place to do things (e.g. in Fedora Forge, Fedora Matrix, etc.). The specific results/deliverables and impact on Fedora Linux would be determined later. Perhaps it would be a spin, perhaps an edition, perhaps something new. When that happens, I am sure it will be done via a Change proposal or a Fedora Initiative er other appropriate means.
Oh, for that kinda thing I'd agree it probably doesn't even need a Change.
I can't find a doc for forming a WG (I *think* WGs can only be designated by FESCo / Council maybe?), but we have a doc for forming a SIG and it's basically self-service:
https://fedoraproject.org/wiki/Creating_a_Fedora_SIG
you just say you're a SIG, file a few tickets to ask for whatever Forge org, chat room, Discourse tag etc. you want, and...you're a SIG! I think that's totally fine for the above.
As there had been some confusion about this: new tags in the Project Discussion category of Discourse can be requested at site administration, not forum moderation, because the tags of this one category are indeed a site admin issue:
https://forge.fedoraproject.org/discussion/tickets -> issues
For this particular case (#hummingbird-sig), the ticket already exists (#3). So no further action necessary.
That said, it has to be clear that tags in this category are carefully considered/evaluated.
And we welcome both (the support, and ruthless technical guidance)! ;-)Thank you Miro!
* Scott McCarty:
What's interesting for Fedora: Project Hummingbird is built using the open source development process, originating from Fedora Linux components (some Rawhide, some Stable). The press release notes that unsupported images are freely available and redistributable, following a similar model to Red Hat Universal Base Image (UBI) [5]. The work is already happening in the open [2] with images available [3].
We'd like to explore bringing this work more formally into the Fedora community and creating a space where this innovation can continue in the open. This would follow similar patterns we've seen with other successful incubation efforts in Fedora like ELN [4].
Would Fedora build the container images on Fedora infrastructure, or would it just re-publish the existing images, which are not built on Fedora infrastructure?
Thanks, Florian
Florian, The initial goal would be to bring the work into Fedora by creating a Forge account and SIG, while nurturing it under the Fedora Innovation Lifecycle proposal described here [1]. This would give us some flexibility and time. It would still be built by Red Hat infrastructure for now, but we'll continue to mature that and figure out what makes sense (creating new infrastructure where necessary, landing on current infra, etc). It's a highly automated project, so I'm confident we'll be able to move the factory over, but it will require special care and feeding.
[1]: https://fedoraproject.org/wiki/User:Jspaleta/Drafts/FedoraInnovationLifecycl...
On Thu, Apr 23, 2026 at 02:19:01AM -0000, Scott McCarty wrote:
Hi all,
Last November, Red Hat announced Project Hummingbird [1], a catalog of minimal, hardened container images designed to accelerate application development with a minimal CVE strategy. The images include the latest languages and runtimes (Node, Go, .NET, Java, Python, Rust, Ruby), developer databases (PostgreSQL, MariaDB), web servers and proxies (Nginx, Caddy, HAProxy), and other foundational components for modern application stacks [3].
Are you fixing CVEs or are these "zero CVE" simply because you're packaging something so new that the problems haven't been found yet? If you're fixing CVEs (good!) then why not contribute those fixes to upstream and Fedora?
TBH I'm unclear what this is for and why anyone would use it.
What's interesting for Fedora: Project Hummingbird is built using the open source development process, originating from Fedora Linux components (some Rawhide, some Stable). The press release notes that unsupported images are freely available and redistributable, following a similar model to Red Hat Universal Base Image (UBI) [5]. The work is already happening in the open [2] with images available [3].
Fedora Rawhide is also freely available and redistributable.
Rich.
Richard, For CVEs, the idea is mostly to close the gap between upstream and downstream. If it's fixed upstream, we want to make sure that it's fixed in our container images. Red Hat, as a whole, still contributes to fixing things upstream, but Hummingbird doesn't really provide any new technology around that. Anything that's not fixed yet, is made transparent to the user.
Historically, security feeds + risk-based CVE patching were enough with RHEL. We've done this successfully for years, and we'll continue to do this. But, there is a new class of users that does not have the time, nor energy to even digest the risk level. They're being mandated to "just patch it" - the upstream stable releases of software have trained user that it's "stable enough" and that the risk of patching is lower than annoyance of red marks on dashboards complaining about CVEs. Think of Kubernetes clusters with very mixed software from many different developers. These are the targeted users.
We have very good data showing that users are interested in this kind of container image. I did some quick research to see if any users had made their usage of Hummingbird public, but couldn't find any (yet). But, suffice to say Ben Breard and I have been on customer calls where they really want to put these into production before they're even GA. Also, you'll see many customer references at Red Hat Summit this year.
This is a very exciting area, and we think it will very valuable to the Fedora community.
On Tue, Apr 28, 2026 at 12:52:05AM -0000, Scott McCarty wrote:
Richard,
For CVEs, the idea is mostly to close the gap between upstream and downstream. If it's fixed upstream, we want to make sure that it's fixed in our container images. Red Hat, as a whole, still contributes to fixing things upstream, but Hummingbird doesn't really provide any new technology around that. Anything that's not fixed yet, is made transparent to the user.
Still my question is how is this different from the Rawhide containers that Fedora publishes today? This creates a container that was built under 24 hours ago:
$ podman pull fedora:rawhide $ podman run -it fedora:rawhide
so putting stuff into Rawhide seems to satisfy this need.
[Snipped something about RHEL that seems to have nothing to do with Fedora]
This is a very exciting area, and we think it will very valuable to the Fedora community.
I'm sure, but I still don't understand what "it" is.
Rich.
Richard W.M. Jones venit, vidit, dixit 2026-04-28 18:55:07:
On Tue, Apr 28, 2026 at 12:52:05AM -0000, Scott McCarty wrote:
Richard,
For CVEs, the idea is mostly to close the gap between upstream and downstream. If it's fixed upstream, we want to make sure that it's fixed in our container images. Red Hat, as a whole, still contributes to fixing things upstream, but Hummingbird doesn't really provide any new technology around that. Anything that's not fixed yet, is made transparent to the user.
Still my question is how is this different from the Rawhide containers that Fedora publishes today? This creates a container that was built under 24 hours ago:
$ podman pull fedora:rawhide $ podman run -it fedora:rawhide
so putting stuff into Rawhide seems to satisfy this need.
[Snipped something about RHEL that seems to have nothing to do with Fedora]
This is a very exciting area, and we think it will very valuable to the Fedora community.
I'm sure, but I still don't understand what "it" is.
From what I understand, with hummingbird you have an image "php" that has just php and what that needs, an image "nginx", ... The example given for curl made me double check which day of April we had, though.
Michael
On Wed, Apr 29, 2026 at 10:05:13AM +0200, Michael J Gruber wrote:
Richard W.M. Jones venit, vidit, dixit 2026-04-28 18:55:07:
On Tue, Apr 28, 2026 at 12:52:05AM -0000, Scott McCarty wrote:
Richard,
For CVEs, the idea is mostly to close the gap between upstream and downstream. If it's fixed upstream, we want to make sure that it's fixed in our container images. Red Hat, as a whole, still contributes to fixing things upstream, but Hummingbird doesn't really provide any new technology around that. Anything that's not fixed yet, is made transparent to the user.
Still my question is how is this different from the Rawhide containers that Fedora publishes today? This creates a container that was built under 24 hours ago:
$ podman pull fedora:rawhide $ podman run -it fedora:rawhide
so putting stuff into Rawhide seems to satisfy this need.
[Snipped something about RHEL that seems to have nothing to do with Fedora]
This is a very exciting area, and we think it will very valuable to the Fedora community.
I'm sure, but I still don't understand what "it" is.
From what I understand, with hummingbird you have an image "php" that
has just php and what that needs, an image "nginx", ... The example given for curl made me double check which day of April we had, though.
Isn't that "How containers work 101"?
So maybe this project is about reducing unnecessary dependencies? Or they 'rm -rf' parts of the filesystem tree that they think no one is going to need?
It should be possible for the advocates of the project to clearly express what the project is doing so we don't need to guess here.
Rich.
On 4/22/26 9:19 PM, Scott McCarty wrote:
What's interesting for Fedora: Project Hummingbird is built using the open source development process, originating from Fedora Linux components (some Rawhide, some Stable). The press release notes that unsupported images are freely available and redistributable, following a similar model to Red Hat Universal Base Image (UBI) [5]. The work is already happening in the open [2] with images available [3].
We'd like to explore bringing this work more formally into the Fedora community and creating a space where this innovation can continue in the open.
Hi,
Thank you for the proposal. I definitely am on board with expanding the available container baseimages shipped by Fedora and based on our packages. Beyond the regular, minimal, and toolbox images, all we have right now as far as I know are the SCLORG images that are heavily coupled with the Openshift s2i tooling.
Can you share a little bit more about how the Hummmingbird development and build processes currently work and how you envision potential integration into Fedora and its infra?
Currently, I see that Hummingbird maintains a monorepo with forked Fedora RPM sources on Red Hat Gitlab.com. It looks like these RPM sources are rebuilt in Konflux as part of the container build process?
For full integration into Fedora, I think it's crucial that the Hummingbird Fedora containers are built directly from sources in Fedora distgit and not a separate repository. Otherwise, packaging work is duplicated and any changes or improvements made aren't automatically contributed back to the Fedora package collection.
Maxwell, thank for your email, I really appreciate your interest in this! I'll respond more inline below...
On Thu, Apr 30, 2026 at 1:44 PM Maxwell G maxwell@gtmx.me wrote:
On 4/22/26 9:19 PM, Scott McCarty wrote:
What's interesting for Fedora: Project Hummingbird is built using the open source development process, originating from Fedora Linux components (some Rawhide, some Stable). The press release notes that unsupported images are freely available and redistributable, following a similar model to Red Hat Universal Base Image (UBI) [5]. The work is already happening in the open [2] with images available [3].
We'd like to explore bringing this work more formally into the Fedora community and creating a space where this innovation can continue in the open.
Hi,
Thank you for the proposal. I definitely am on board with expanding the available container baseimages shipped by Fedora and based on our packages. Beyond the regular, minimal, and toolbox images, all we have right now as far as I know are the SCLORG images that are heavily coupled with the Openshift s2i tooling.
I agree, I think these images are particularly valuable to the Fedora Community!
Can you share a little bit more about how the Hummmingbird development and build processes currently work and how you envision potential integration into Fedora and its infra?
Currently, all of the development is done open source, feel free to poke around here: https://gitlab.com/redhat/hummingbird/containers I don't think we have a clear vision yet for how this fits into Fedora infrastructure, yet. Hummingbird is highly automated and currently uses a significant portion of Red Hat's Konflux resources. We'll need to figure out how to fund and build that, etc. We're hoping to have deeper conversations at Flock where a bunch of us will be. I expect Valentin Rotherberg and Robert Sturla (the brains behind all of this), Harrison Ripps, Stef Walters, myself, and potentially a few others to be there.
Currently, I see that Hummingbird maintains a monorepo with forked Fedora RPM sources on Red Hat Gitlab.com. It looks like these RPM sources are rebuilt in Konflux as part of the container build process?
That's correct, it's a monorepo, and everything is rebuilt with a similar set of "specifications" (fips, builder images, STIG, CIS, SCAP, etc). It's a fairly large list of features built into the images, which I think makes them a good fit for many users in 2026.
For full integration into Fedora, I think it's crucial that the Hummingbird Fedora containers are built directly from sources in Fedora distgit and not a separate repository. Otherwise, packaging work is duplicated and any changes or improvements made aren't automatically contributed back to the Fedora package collection.
We're discussing a lot of this. Brent Baude and I were just discussing this the other day, there is some technical debt associated with getting these things out of sync, and we definitely want to find a better long term solution. Looking forward to having more discussions about this.
Kind Regards Scott M
On Thu, 2026-04-30 at 12:39 -0500, Maxwell G wrote:
On 4/22/26 9:19 PM, Scott McCarty wrote:
What's interesting for Fedora: Project Hummingbird is built using the open source development process, originating from Fedora Linux components (some Rawhide, some Stable). The press release notes that unsupported images are freely available and redistributable, following a similar model to Red Hat Universal Base Image (UBI) [5]. The work is already happening in the open [2] with images available [3].
We'd like to explore bringing this work more formally into the Fedora community and creating a space where this innovation can continue in the open.
Hi,
Thank you for the proposal. I definitely am on board with expanding the available container baseimages shipped by Fedora and based on our packages. Beyond the regular, minimal, and toolbox images, all we have right now as far as I know are the SCLORG images that are heavily coupled with the Openshift s2i tooling.
Minor note: there are also (at least) the atomic desktop bootc images and the bootc images built out of the Fedora-IoT compose, Fedora-base- bootc and Fedora-IoT-bootc. Fedora-base-bootc is built there for...reasons?...I think it was supposed to get moved into the main compose at some point.
Hi Scott,
So I'm a bit late to this and have read the thread, also asked a few people.
Last November, Red Hat announced Project Hummingbird [1], a catalog of minimal, hardened container images designed to accelerate application development with a minimal CVE strategy. The images include the latest languages and runtimes (Node, Go, .NET, Java, Python, Rust, Ruby), developer databases (PostgreSQL, MariaDB), web servers and proxies (Nginx, Caddy, HAProxy), and other foundational components for modern application stacks [3].
I mean that sounds interesting...
What's interesting for Fedora: Project Hummingbird is built using the open source development process, originating from Fedora Linux components (some Rawhide, some Stable). The press release notes that unsupported images are freely available and redistributable, following a similar model to Red Hat Universal Base Image (UBI) [5]. The work is already happening in the open [2] with images available [3].
I mean Fedora is built using "the open source development process" too. The press release on the other hand is mostly marketing hype for enterprise types... it's like "Florals for Spring... groundbreaking!"
We'd like to explore bringing this work more formally into the Fedora community and creating a space where this innovation can continue in the open. This would follow similar patterns we've seen with other successful incubation efforts in Fedora like ELN [4].
Most of the 'incubation' efforts like ELN benefit RH and not the community, eg ELN is building rawhide with RHEL constraints for the next RHEL, I've mostly found that ELN makes more work for me and does provide benefit.
I'd be interested to know how Hummingbird solves problems for the community rather than RH piling more work and expectations on the community.
Before we go down the formal Change Proposal path, I wanted to gauge community interest and see if there's appetite for this kind of project.
I would like to see a lot more architectural details on the website. On the main page it mentions "minimal, hardened, and secure container images" ... I mean ground breaking (last decade!) but when I dig into details I get very little.
I go to the background [1] section and it mentions rpms, container repos and such but what I'm really interested in is you mention in threads it uses rpms, and Fedora and rawhide and upstream. It doesn't go into that detail.
When I dig into user and developer flow it mostly just covers pretty standard container workflows.... again ground breaking!
What I would really like to see is not the marketing fluff and basic documentation but an architectural overview on the website that shows that this isn't just jamming a bunch of rpms into a container, probably doing some form of donkey patching for upstream CVEs and shoving it out into a container repo. I would have expected there to be some details of the actual architecture on the web site.
Then knowing the above why I would want to see this in Fedora, what value does it provide to me and the community and others outside of RH, and that it's not just some more outsourcing of RHEL development to Fedora to dump stuff in the ecosystem without any real value to them to make Hummingbird easier for RH to use for their paying customers.
Peter
-
Adam Williamson -
Christopher Klooz -
Daniel Walsh -
Florian Weimer -
Maxwell G -
Michael J Gruber -
Miro Hrončok -
Neal Gompa -
Peter Robinson -
Richard W.M. Jones -
Scott McCarty -
Simon de Vlieger