The F44 election interviews are now live. With seats open across all leadership groups, this is one of our most popular election cycles yet! Use this post to navigate to candidates interview posts easily.
Voting will be open on Monday, June 1st and will close at 23:59 UTC on Friday, June 12th. Best of luck to all our candidates!
This is a part of the Fedora Linux 44 EPEL Steering Committee Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.
Interview with Jonathan Wright (jonathanspw)
What is your name and what is your FAS ID?
Jonathan Wright, jonathanspw
What is your background in EPEL? What have you worked on and what are you doing now?
I’ve been a consumer of EPEL for…a long time. 20 years? I’ve been a contributor to EPEL for about the past 5, and on the EPEL steering committee for the past year.
EPEL is very near and dear to my heart and is actually how I got involved with Fedora. I’m on the AlmaLinux team and like everyone else, the first thing I do when installing AlmaLinux (previously CentOS) is dnf install epel-release. I’ve successfully graduated packages from EPEL that ultimately got picked up by RHEL (see Valkey) and work to make EL distros more usable by having an array of package availability that’s not otherwise available without EPEL.
Why are you running for EPEL Steering Committee member?
I have a unique perspective to bring to the table with my history in web hosting and long time usage of RHEL and its clones (CentOS and now AlmaLinux). The past year serving on the EPEL steering committee has been a great honor and I hope to continue in that role for another year.
This is a part of the Fedora Linux 44 EPEL Steering Committee Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.
Interview with Diego Herrera (dherrera)
What is your name and what is your FAS ID?
Name: Diego Herrera
FAS ID: dherrera
What is your background in EPEL? What have you worked on and what are you doing now?
My relationship with open source started back in 2006, and I’ve been an advocate since, both by contributing to various projects and by publishing my own. My deep dive into EPEL began in 2013 while working in a company doing R&D work for local industries, where I gained my first practical experience with RPM packaging. This early work gave me a solid understanding of what it means to build and manage software within the Enterprise Linux context.
More recently, I joined Red Hat in 2021 to work as part of the CLE Team, where I deepened my understanding of how to become a proper Fedora packager and contributor. I have been working together with Carl George, focusing on the needs of EPEL by participating in steering meetings and doing work regarding the project’s infrastructure. Through this position, I was able to participate in activities such as packaging, writing documentation and SOPs, collaborating on maintenance work required for the infrastructure, and improving infrastructure automation. Furthermore, during steering meetings, I have been able to add my viewpoints and insights when they were needed, and I was also able to take on some of the steering team’s workload, such as the Forgejo migration.
Why are you running for EPEL Steering Committee member?
Over the last few years, while spending time on the infrastructure side of the project, I’ve seen first-hand the ups and downs of the project, which has enabled me to collaborate closely with members of the community.
The EPEL steering committee is already a place where I have been able to use my experience and knowledge to support and contribute to the project. However, this time I want a vote on these topics. This will allow me to collaborate further, helping to turn those discussions into a better path for the project. I want to continue helping the community so that the project can continue to grow into a great platform by ensuring our governance is as solid and reliable as our processes.
For the sake of transparency, even if I wrote the text myself, I also used a local LLM (Gemma4:e4b) to iteratively fix the text’s grammar and flow.
This is a part of the Fedora Linux 44 EPEL Steering Committee Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.
What is your background in EPEL? What have you worked on and what are you doing now?
I got my start in Fedora and EPEL in 2014. I was working for Rackspace and joined a team whose primary purpose was to maintain IUS, a third-party package repository for RHEL. Part of my work there involved contributing to and maintaining EPEL packages. I left Rackspace in 2019 to join the CentOS team at Red Hat. In 2021, I started a new team at Red Hat to specifically focus on EPEL activities.
During my time on the EPEL team, I’ve lead the design and implementation of EPEL 9 and EPEL 10. These releases each brought significant improvements to packager workflows and user experience, especially the introduction of minor versions in EPEL 10. We’re currently in the early days of planning EPEL 11, with a focus on continued refinement and quality.
Aside from the hands-on technical work of EPEL release engineering and packaging, I routinely attend conferences to deliver presentations about EPEL and staff Fedora/CentOS booths to engage with the EPEL community. I enjoy mentoring new packagers and helping existing Fedora packagers get started with EPEL.
Why are you running for EPEL Steering Committee member?
I have been on the EPEL Steering Committee since 2020. I have enjoyed my six years serving on the committee, and hope to have the opportunity to continue this important work. I am passionate about EPEL and I am committed to continue finding ways to improve the EPEL experience for both packagers and users.
This is a part of the Fedora Linux 44 EPEL Steering Committee Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.
Interview with Troy Dawson (tdawson)
What is your name and what is your FAS ID?
Troy Dawson (tdawson)
What is your background in EPEL? What have you worked on and what are you doing now?
I started contributing to EPEL 11 years ago with some nodejs packages for OpenShift. I later added rubygems and golang packages as OpenShift changed languages. Later, RHEL 8 did not have KDE, so I added KDE to epel8, and have been maintaining KDE in epel ever since. I have picked up many other packages during the years, but I think my KDE contributions are what I am most known for.
I’ve been the EPEL Steering Committee chair since 2020, taking over from Stephen Smoogen. A lot of changes have happened since then, most of them for the better. I’m not responsible for all the changes, but it’s been wonderful being part of the committee as these changes have come through.
Why are you running for EPEL Steering Committee member?
EPEL has grown to be part of my professional and personal life. I not only want to contribute to it, but help steer it’s growth and progression. I think as a EPEL Steering Committee member, I can help keep EPEL healthy and thriving.
This is a part of the Fedora Linux 44 Mindshare Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.
Please elaborate on the personal “Why” which motivates you to be a candidate for Mindshare
Technology might be why I joined the Fedora Project, but I stayed because of the people who made me feel at home. Progressing in various aspects of our planned functions over the past years has taught me one crucial thing – contributors are actually retained when they feel noticed, supported and trusted with meaningful work. The Mindshare Committee is where that happens, and I want to keep building what we started.
Furthermore, as the committee’s representative to the Fedora Council, I have seen firsthand how decisions at the governance level shape the contributor experience on the grassroots level. The update during the Fedora Council Strategy Summit 2026 gave us an opportunity to serve event organizers, community ambassadors and voluntary contributors better, all while using these outcomes to enhance the community health.
How would you improve Mindshare Committee visibility and awareness in the Fedora community?
Simple. We need to show up where the community is. A community booth in one event, some interactive workshops in another – to begin with in regional event support to ultimately show people that we indeed care. While making sure that our infographic swagpacks are updated on a regular basis in digital ambassadorship, we actually ensure that we are providing people with reasons to come back to us when the time is right.
With the upcoming collectible rarity feature in Fedora Badges and tangible contributor recognition awards (both as a part of Fedora Mentor Summit event and separately), we nudge people to more opportune contribution avenues while avoiding burnouts in longtime contributors. This could further be extended to our Fedora Linux Release Parties too, as ultimately, most of our community members started off as its users.
What part of Fedora do you think needs the most attention from the Mindshare Committee during your term?
Contributor Recognition. With over half a decade of experience in this space, the “What now?” problem (after the first contribution) has only become worse with the advent of AI Assisted Contribution Activities. Newcomers struggle to realize the value proposition of the community connection that Fedora Project could provide, and hence, it has become the need of the hour to incentivize contributions using rewarding activities.
But apart from that, we also need to do better at further improving our local presence in underrepresented regions. In this past term, my pilot experiment on APAC events worked wonders, and it showed us all the community power we can tap into by just being there. With reusable swagpacks, localized printing, active conversations and documented accounts, this limited experiment can scale well across various parts of the globe.
This is a part of the Fedora Linux 44 Mindshare Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.
Interview with Mackenzie Stewart (monkeybean12)
FAS ID: monkeybean12
Matrix Rooms: I tend to use these Matrix channels, Fedora, Fedora EPEL Matrix, Announcements, Introductions.
Questions
What is your background in Fedora? What have you worked on and what are you doing now?
My background in Fedora is using the Java programming language from Oracle and I have worked on games and graphics with Java language. I am currently writing computer programs for other computer languages which are Python, JavaScript in nodeJS and Building/Maintaining WordPress websites using PHP, HTML5 and CSS3.
Please elaborate on the personal “Why” which motivates you to be a candidate for Mindshare
I want to help bring people together and support the culture around Fedora, not just the technical work. Fedora is more than just an operating system to me — it’s a community. I want everyone who contributes, whether they code, design, or help run events, to feel valued and know their work matters.
How would you improve Mindshare Committee visibility and awareness in the Fedora community?
I would propose a recurring, informal ” Monthly Community News” session—open to all—where Mindshare members discuss why certain decisions were made, rather than just reporting the results. Also to be a place for any updates or events to be introduced or announced so that it may generate more interest to all.
What part of Fedora do you think needs the most attention from the Mindshare Committee during your term?
Mindshare should act as the “connective tissue.” I want to focus on creating a standardized, project-wide mentorship framework that assists sub-projects in bringing in new contributors.
This is a part of the Fedora Linux 44 Mindshare Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.
Interview with Mat Holmes (theprogram)
FAS ID: theprogram
Matrix Rooms: Join, Fedora, Fedora Social, DEI, Mindshare, Design, Council, CommOps, Server, Docs. I also monitor technical channels, but try not to distract people there too much.
Questions
What is your background in Fedora? What have you worked on and what are you doing now?
I started with Fedora through Discussion, our Fedora Help Desk. This helped me both learn and teach about Fedora. Once I found Matrix, I quickly got involved as a member and sponsor with Join, where I to this day very much enjoy meeting and welcoming many new people. As I continued over the past couple of years, I have progressed to many people facing roles such as helping with DEI and CommOps. I also stick my beak into Mindshare and Council topics while trying to not step on peoples toes. These days I have started writing Docs such as the Beginners Guide to Fedora and I am now helping with Server where we are developing new Beginners Guides to Server and the upcoming Home Lab.
Please elaborate on the personal “Why” which motivates you to be a candidate for Mindshare
Mindshare suites me very well as I have extensive experience organising events and doing outreach for professional organisations such as Amnesty International Australia and a political party (which I won’t name as politics is too divisive – but feel free to ask me about it).
My personal motivation is that I enjoy working with people in the Fedora community.
How would you improve Mindshare Committee visibility and awareness in the Fedora community?
The role of Mindshare has changed over the last couple of cycles to be more focussed on events. I would promote people to talk early and often to us, so we can put more smaller events on the table.
What part of Fedora do you think needs the most attention from the Mindshare Committee during your term?
I think Mindshare needs a clearer idea of what budget we have to work with, and we need faster responses to ticketed issues. We also need to improve the accessible roads to ambassadorship, both in person and digital. Taking my skills from Join, I would extend this to being available to help plan broader small group involvement with communities all over the globe.
This is a part of the Fedora Linux 44 Mindshare Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.
Interview with Samyak Jain (jnsamyak)
FAS ID: My FAS username is jnsamyak, and most people in the community know me by jnsamyak as well
Matrix Rooms:#releng:fedoraproject.org #admin:fedoraproject.org #release-day:fedora.im #devel:fedoraproject.org #mindshare:fedoraproject.org #social:fedoraproject.org #design:fedoraproject.org Along with many contributor onboarding, event coordination, and Fedora community discussions across Matrix.
Questions
What is your background in Fedora? What have you worked on and what are you doing now?
I currently work as a Fedora Release Engineer and have helped lead multiple Fedora Linux releases, including Fedora Linux 42, Fedora Linux 43, and most recently Fedora Linux 44. My work primarily involves release coordination, compose workflows, branching, signing operations, automation improvements, and ensuring smooth release execution across Fedora infrastructure.
Over time, I’ve also contributed toward improving release documentation, mentoring contributors, coordinating release-day activities, and helping newer contributors understand Fedora Release Engineering workflows.
Before Fedora, I contributed to Debian, primarily around Kotlin and Ruby packaging. When I joined Fedora, one of the first things that stood out to me was how welcoming and community-driven Fedora felt. Fedora India meetings became my first real social entry point into the Fedora ecosystem, and from there, I gradually became more involved in both technical and community activities.
Beyond Release Engineering, my Fedora journey has always been deeply community-focused. Some of the initiatives and events I’ve been involved in include:
Co-organizing Fedora Hatch Pune 2022
Leading Fedora’s involvement and organization efforts for GNOME Asia 2024 in Bangalore
Representing Fedora at Flock 2025
Representing Fedora at FOSSASIA 2026 to strengthen Fedora’s APAC visibility and outreach
Speaking at conferences like DevConf.cz, DebConf, GNOME Asia, and Fedora events
Supporting contributor onboarding and mentorship across APAC communities
One experience that particularly shaped my perspective was attending FOSSASIA 2026 as part of Fedora’s APAC outreach efforts. It gave me a much broader understanding of how rapidly open source communities are growing in Asia and how different communities actively engage contributors in the region.
That experience reinforced something important for me: Fedora already has incredible technical foundations and strong community values — but we can do much more in terms of visibility, onboarding, storytelling, and contributor engagement across APAC.
I also currently serve as an Outreachy mentor for the Fedora Release Planner Scheduler project, helping contributors navigate Fedora workflows, collaboration practices, and open source contribution processes.
For me, Fedora has never been only about releases or infrastructure. It has always been about building a welcoming and empowering community around open source.
Please elaborate on the personal “Why” which motivates you to be a candidate for Mindshare
My motivation comes from the grassroots experiences I’ve had throughout my Fedora journey. I’ve experienced Fedora from multiple perspectives:
As a newcomer entering the community
As a packager and contributor
As a Release Engineer
As an event organizer
As a mentor helping newer contributors
And one thing became very clear to me: communities do not grow only through technology — they grow through people feeling connected, supported, recognized, and welcomed.
Mindshare sits at the center of that experience.
A major part of this motivation comes from my experiences in APAC communities. I’ve met incredibly talented contributors who often remain unseen simply because they lack visibility, opportunities, guidance, or regional representation. I want to help change that.
Mentoring contributors through Outreachy and interacting with contributors during conferences like FOSSASIA and Flock made me realize how important human connection is in open source communities. Many contributors do not stay because of technology alone — they stay because:
Someone guided them
Someone encouraged them
Someone followed up with them
Someone made them feel like they belonged
That is one of the biggest reasons why I want to contribute more actively through Mindshare. My goal is not just to organize events or discussions, but to help create:
Better contributor journeys
Stronger regional connections
More approachable onboarding
More visible contributor recognition
More interactive and welcoming community spaces
Fedora’s vision talks about creating a world where everyone benefits from free and open source software built by inclusive and welcoming communities. That vision strongly resonates with me, and I want to actively help bring that vision closer to reality.
How would you improve Mindshare Committee visibility and awareness in the Fedora community?
I believe Mindshare visibility improves when contributors can clearly see its impact in their day-to-day Fedora experience. Right now, many contributors still don’t fully know what Mindshare does, how it supports contributors, how regional communities can engage with it, or how contributors can benefit from its initiatives.
I’d like to focus on making Mindshare feel more visible, approachable, interactive, and community-connected across three areas:
Regional Community Spotlights
Introduce lightweight contributor and regional showcases highlighting APAC contributors, Fedora event organizers, mentors and advocates, community success stories, and new contributors making an impact. Sometimes even a simple spotlight can motivate someone to contribute more.
Better Contributor Onboarding and Retention
Help encourage contributor roadmaps by interest area, beginner-friendly onboarding guides, mentorship checkpoints, lightweight follow-up systems, and easier discovery of Fedora teams and opportunities. The contributor journey should feel exciting — not confusing.
Stronger APAC Engagement
Encourage more regional collaboration, Fedora representation at local FOSS events, community-driven mini events and workshops, localized outreach content, timezone-friendly engagement opportunities, and better contributor recognition from APAC communities. There are many hidden Fedora heroes across APAC, and I want to help amplify their stories.
More Interactive DEI Engagement
Explore more interactive approaches such as regional contributor stories, Fedora social storytelling campaigns, contributor experience videos, cultural exchange sessions, community-led DEI discussions, and language-inclusive engagement initiatives. Sometimes even a small welcoming effort can have a lifelong impact on someone entering open source for the first time.
What part of Fedora do you think needs the most attention from the Mindshare Committee during your term?
The biggest area that needs attention is contributor growth and retention — especially across underrepresented regions like APAC. I would specifically focus on three major areas:
1. APAC Visibility and Contributor Recognition
There is immense untapped contributor potential in APAC. I want to help improve regional visibility, encourage local leadership, increase contributor recognition, strengthen cross-community collaboration, and build a stronger regional Fedora identity. Even small recognition efforts can significantly motivate contributors and make them feel valued.
2. Contributor Retention and Mentorship
We need smoother and more approachable contributor journeys. I’d love to help encourage structured onboarding pathways, defined contributor milestones, team-specific starter guides, mentorship and feedback loops, easier first-contribution experiences, and better newcomer follow-up systems. The goal is simple: make contributors feel supported from their very first interaction with Fedora.
3. Human-Centered Community Building and DEI
Fedora is one of the most technically strong communities in open source, but what truly makes it special is its people. I want to help strengthen community interaction, social engagement, inclusive participation, DEI-focused storytelling, contributor appreciation, and community belonging.
Ultimately, I want Fedora to continue being a place where contributors from every background feel welcomed, valued, heard, and inspired to stay.
While contributors may forget specific technical tasks over time, they always remember how a community made them feel.
This is a part of the Fedora Linux 44 Mindshare Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.
Interview with Luis Bazan (lbazan)
FAS ID: lbazan
Matrix Rooms: All channels! A lot.
Questions
What is your background in Fedora? What have you worked on and what are you doing now?
My experience with Fedora has involved working and collaborating with the community at both national and international levels, encouraging people of all ages to use and contribute to Fedora. I have worked closely with several countries to help support their growth, maintain community engagement, and motivate contributors to continue participating in the Fedora Project.
Please elaborate on the personal “Why” which motivates you to be a candidate for Mindshare
My main motivation, and what has always kept me connected to the Fedora community, is contribution, networking, and the friendships I have built within it. Beyond that, I truly value being able to continue motivating more people to stay involved in the project.
In my opinion, this is one of the most challenging parts of being a contributor: helping more users and engineers become interested in contributing and encouraging them to continue participating in some way within the Fedora Project.
How would you improve Mindshare Committee visibility and awareness in the Fedora community?
To improve the visibility and awareness of the committee, we should continue working on the plans that are already in progress, because these are not tasks that can be completed in a single day. These initiatives require time to mature in order to improve processes that benefit contributors and the community. The goal is not to make processes more complex, but to improve them so they remain effective and practical for collaborators. This takes time, in addition to the many other responsibilities we manage on a daily basis.
What part of Fedora do you think needs the most attention from the Mindshare Committee during your term?
I believe that the area requiring the most attention is related to events and budgeting. We have had tickets and requests that did not move forward because either the requirements process was not fully understood or the process itself was not completed properly. We should be more open and supportive in this area, especially regarding swag and other resources for smaller events organized in different countries around the world.
This is a part of the Fedora Linux 44 Council Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.
Interview with Miro Hrončok (churchyard)
FAS ID: churchyard (you may also find me as mhroncok)
Matrix Rooms: python:fedoraproject.org, devel:fedoraproject.org, council:fedoraproject.org, and many more
Questions
What kind of experience do you have which might be relevant to the role? E.g Governance, leadership, etc.
I’ve been an active Fedora contributor for over 12 years, co‑maintaining the Python and 3D‑printing stacks and sponsoring new packagers. I served on FESCo for 5 years and I’ve been on the Council for 1 year. Technically I am on the Fedora Packaging Committee as well, but I am not very active there nowadays.
Through those roles I’ve gained understanding of how Fedora is built and governed. I wish to keep that experience in the Fedora Council and ensure that the people who do the day‑to‑day work of creating Fedora Linux have a strong, informed voice at the table.
I spent my first year on the Council mostly orienting myself and I am not very satisfied with my accomplishments (or lack thereof). I was contemplating whether to not run again or to try harder. As you are reading this interview, it means I decided for the latter
What do you see as potential opportunities and risks for the Fedora Project?
My overall feeling after spending a year in this role is that there is this abyss between the Council and all the folks doing all things Fedora, like packaging. On one hand, we speak about initiatives, visions, and goals. On the other hand, there is Fedora Linux and people who make it. And I don’t feel like one hand knows what the other hand is doing. This has been frustrating to me and I decided to try to bridge that gap. I don’t have a ready-made solution for this yet, but it’s something that I strongly believe needs to be addressed and reflected in what Council is doing, approving, proposing.
Related to this, I feel that there is a more general risk of fragmentation of the community. For example, we seem to have moved some communication to discussion.fedoraproject.org while we kept others on the mailing lists. This move was a great opportunity to get more people involved in project discussions. At the same time, we risk losing the existing contributors. In the end, it seems we have two almost distinct groups of people who don’t talk to each other much.
No matter how many new contributors we get, we should not lose the existing ones, who are driving the project.
What brought you to the Fedora Project?
It was actually 3D printing. Back in the day, we had a lab at the university with 1 (one) Prusa Mendel in it and I wanted to package some 3D printing apps like Skeinforge, Slic3r or Printrun for Fedora. I attended an RPM packaging workshop in the Brno Red Hat office and started packaging. Not long after that I became a Fedora Ambassador, bringing the 3D printer to the Fedora booth at conferences.
This is a part of the Fedora Linux 44 Council Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.
What kind of experience do you have which might be relevant to the role? E.g Governance, leadership, etc.
In previous years, I was a member of FESCo, where I gained exposure to the governance of the technical side of the Fedora Project.
In my professional life, I currently serve in a leadership role as Product Owner of the Community Linux Engineering team at Red Hat. Our team is responsible for a wide range of areas across the Fedora Project, including Quality Engineering, EPEL, Design, Infrastructure, and Release Engineering.
This gives me a unique perspective that combines community experience, technical understanding, and insight into how Fedora is supported inside Red Hat.
What do you see as potential opportunities and risks for the Fedora Project?
Opportunities
Immutable Desktop Fedora is well positioned for the shift toward immutable and image-based operating systems. Projects like Fedora Silverblue and Kinoite already provide atomic updates and rollback capabilities while maintaining a strong developer experience.
Cloud-Native and Edge Computing With Fedora CoreOS and Fedora IoT, Fedora already has strong foundations for container-focused and edge deployments. As these technologies continue to grow, Fedora can remain one of the leading platforms for modern infrastructure.
The Open AI Workstation Developers increasingly want reliable environments for running local AI workloads and experimenting with open models. Fedora has an opportunity to become the preferred Linux workstation for this use case through strong hardware enablement, modern tooling, and fast adoption of new technologies.
Early Technology Adoption Fedora has built a reputation for bringing important new technologies to Linux users early, whether that was systemd, Wayland, PipeWire, or Btrfs. That culture of innovation continues to attract developers and contributors who want to help shape the future of Linux.
Risks
Balancing Community and Corporate Influence Fedora benefits enormously from Red Hat sponsorship, engineering support, and infrastructure. At the same time, maintaining community trust and independence remains critically important. Long-term success depends on keeping a healthy balance between corporate priorities and the Fedora community ethos.
Project Fragmentation Fedora continues to grow across Spins, Labs, Editions, Atomic variants, and now containers. Growth is healthy, but it also increases the complexity of maintaining consistent quality, direction, and contributor focus across the project.
User Experience vs. FOSS Purity Fedora’s commitment to free and open-source software is one of its greatest strengths. However, hardware enablement and multimedia support can still be frustrating for many users. Fedora should continue improving the onboarding experience without compromising its principles.
Competition The Linux ecosystem is moving quickly. Arch Linux attracts many advanced users, Ubuntu remains dominant in commercial environments, and NixOS is gaining momentum among developers interested in reproducible systems and declarative infrastructure. Fedora needs to continue innovating while preserving the strengths that make the project unique.
What brought you to the Fedora Project?
As a user, I was basically forced by my older brother to use Fedora Core 1-3 on our shared family computer.
After a few years of distro hopping, I eventually returned to Fedora because it consistently provided modern software without requiring the amount of maintenance that distributions like Arch Linux demanded at the time.
After years of using Fedora, I wanted to give something back to the community. I started contributing through packaging and co-maintaining several Node.js and Ruby packages.
Later, I had the opportunity to join the Fedora Project professionally as part of the Release Engineering team. Over time, I transitioned into my current role as Product Owner for the team supporting Fedora inside Red Hat.
Today, I have visibility into how work is prioritized across the teams that provide Fedora infrastructure and services, support release engineering and quality processes, and contribute to areas like EPEL, Docs, and Design.
This brings me to the current Council elections. I believe Fedora is at an important crossroads. The project continues to grow, but at the same time, the distribution and contributor experience are becoming increasingly fragmented across Spins, Labs, Atomic variants, containers, and specialized deliverables.
I believe Fedora’s biggest challenge over the next few years will not be innovation. Fedora has always been good at innovation. The real challenge will be maintaining a clear identity, a healthy contributor community, and a coherent user experience while continuing to grow.
This is a part of the Fedora Linux 44 Council Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.
Interview with Fabio Valentini (decathorpe)
FAS ID: decathorpe
Matrix Rooms: Too many to list them all: #devel, #rust, #epel, #multimedia, #pride, #python, #quality, #security, … (on the fedoraproject.org homeserver)
Questions
What kind of experience do you have which might be relevant to the role? E.g Governance, leadership, etc.
I have served as a member of FESCo for six terms since I joined the project, and have also been a member of the Packaging Committee for over eight years now. In these roles (among others) I have gathered experience in a variety of both technical and non-technical areas including problem resolution, technical discussions, project management, technical writing / documentation, organizing meetings, etc.
What do you see as potential opportunities and risks for the Fedora Project?
I think it will be increasingly important to keep the balance between what makes Fedora successful and things that end up being costly distractions – to continue integrating new technologies into a modern, but stable distribution, while avoiding adoption of dead-end or unsustainable technologies from the current hype cycle.
What brought you to the Fedora Project?
Fedora is where my distro-hopping days unexpectedly ended a little over a decade ago. It has felt like home since.
This is a part of the Fedora Linux 44 Council Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.
Interview with Aleksandra Fedorova (bookwar)
FAS ID: bookwar
Matrix Rooms: Usually #council, #fedora-ci, #mine-with-fedora
Questions
What kind of experience do you have which might be relevant to the role? E.g Governance, leadership, etc.
For some time I was an admin of the Russian Fedora Remix services – maintained the site and the wiki. I also participated in moderation of some of our IRC, Jabber channels and forums, which gave me quite a lot of experience in dealing with the folks which are not necessarily IT experts and professionals.
I am also a proud survivor of the GNOME 3 and systemd debates there
Professionally I have worked as a support engineer, build/devops/CI engineer, team lead and product owner, which gives me a range of experience covering quite a lot of “non-coding but still engineering” topics. And I generally believe that there is a lot more in engineering than just writing code.
I also have been on the Fedora Council for some time now. I can not say I really know how to do this council thing correctly, but I am doing my best.
What do you see as potential opportunities and risks for the Fedora Project?
I believe that the general interest in Linux and Fedora in particular is on the rise, and we as a distribution currently are well placed to provide a lot of things people are looking for – stable base, variety of options, fast moving layers on top of integrated foundation and so on. It comes with the risk though as we just might spread too thin trying to cover all possible use cases, all the emerging technologies and all kinds of sometimes contradicting goals.
Our current project model, while open and community-driven, is still rather centralized.
As a big fan of the idea of federation, I believe that going forward we need to learn how to work with the wider ecosystem without necessarily pulling every connected piece into the same project hierarchy.
As a former Fedora Remix user myself, I see remixing(*) as one of the core ideas, which can help us turn a single distribution into a some sort of constellation of distributions. And while each remix may be managed by different groups and different rules, they still need to have a good collaborative relationship, a way to discuss and communicate changes, or to coordinate shared efforts. Of course they also need a way to communicate and share the load and costs.
(*) Here I use a word “remix” in the widest possible sense as in anything which uses Fedora content as a base, no matter what kind of content is added on top and what format of the deliverable is built from it.
What brought you to the Fedora Project?
Even though currently I work as a software engineer, I started to use Fedora not as a coder but as a user. I needed LaTeX to write my Master’s and PhD thesis, and at that time the support for LaTeX(with Cyrillics) was really only working on Linux. Big thanks to Tom (spot) Callaway who still packages texlive for Fedora.
So essentially I chose Linux (and Fedora) because it was the easiest thing for me to use.
Of course the name also did play a role. The more common Linux distribution choices in my community at the time were Gentoo or Slackware. People were talking how “Linux is about choice” and that sort of thing. But once I learned a bit more about the ideas behind different Linux distributions, I really got hooked on the concept of an integration, rather than customization.
The Upstream First principle in particular was rather eye-opening for me. The idea that you should not just build a system for your own needs – that is what the local folks were doing – but that you need to share and contribute those changes back, or at least to discuss them with the original developers to understand their thought process and the choices they made.
I always looked at my Fedora system not as a thing to tweak for my personal needs, but as a path to become a part of a larger community.
This is a part of the Fedora Linux 44 Council Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.
What kind of experience do you have which might be relevant to the role? E.g Governance, leadership, etc.
While I don’t have formal governance experience, I’m an active contributor to several teams and organizations focused on image-based systems. This is the very area where Fedora is leading innovation. This gives me both technical depth in Fedora’s modern directions and practical insight into how image-based approaches are being adopted across the ecosystem. Additionally, as an independent contributor, I bring a perspective focused on the broader community’s needs.
What do you see as potential opportunities and risks for the Fedora Project?
Fedora’s leadership in image-based systems is a significant opportunity. The Atomic Initiative is advancing this space meaningfully. However, when such initiatives conclude, we must ensure contributors remain engaged and their work integrates into sustainable community practices.
More broadly, as AI becomes increasingly present in development workflows, we need thoughtful governance around how Fedora engages with it. This is about authorship, accountability, and the moral questions around code provenance and community contribution. Fedora’s values should guide how we engage with these technologies responsibly.
What brought you to the Fedora Project?
I initially needed an OS for on-premise servers, which led me to CentOS. The transition forced a reassessment, and during that process, I discovered Fedora’s emerging work on image-based systems. That discovery led me to get involved in related teams, which deepened my commitment to this community. Now, as an active contributor in that space, what keeps me here is the community itself. I’m inspired by it, and that’s what drives my continued involvement.
This is a part of the Fedora Linux 44 Council Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.
What do you see as potential opportunities and risks for the Fedora Project?
One of the first things that comes to my mind about risks for our community is decision transparency. The discussions [1][2] around the AI Developer Desktop Proposal were a valuable learning experience as they showed how much community members care about understanding why we vote the way we do, not just what we voted for. I see an opportunity here for elected members to share their reasoning with their votes on a given proposal, so others can follow the thought process. After all, I would want to vote for someone who engages with what the community has to say and is willing to show their work, even through various disagreements.
To dive even deeper, we also risk alienating the community members by deciding on a certain proposal before it is theoretically ready to be discussed. While a stopgap opportunity here might be ratifying a proposal readiness guidelines document that the members could refer to, in my honest opinion, being active around the Fedora Project community platforms just ends up helping a lot more. If this requires us to spend more hours around the desk, have more frequently organized synchronous meetings, include more electable Fedora Council seats or set regular Fedora Council social hours – then it is something that we need to account for.
Beyond transparency, I also want to champion process sustainability in our established processes. The end of an elected member’s term should not mean that their ongoing work disappears – it should be (or made) possible for incoming candidates or continuing members to carry forward and iterate upon that work. Similarly, we can reduce the risk of potential burnouts among elected members by effectively delegating to the enthusiastic contributors that our community is never short of. Good governance should outlast any single term, and I want to actively work towards building that continuity through documenting better handoff practices.
What brought you to the Fedora Project?
Video games. Back in early 2020 when we were isolated at our homes due to COVID-19 pandemic, all I had was a weak laptop and a Fedora Workstation setup to keep me from boredom. One of my first contributions had been to the Quick Docs. When I thought I was done with my contributing activities, friends like Ankur Sinha, Alberto Sanchez, Justin Wheeler, Marie Nordin, Nasir Hussain, Vipul Siddharth etc. just made me keep coming back for more. Then getting inspired from all the amazing stuff they got up to back in the day made me want to see if I could be of some help – and a huge reason why I am keeping myself busy even today is just that.
This is a part of the Fedora Linux 44 Council Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.
What kind of experience do you have which might be relevant to the role? E.g Governance, leadership, etc.
To strengthen my governance knowledge, I recently completed two courses on governance fundamentals. (Governance Training, and Tools for Project Planning)
I am also familiar with meeting procedures, including how meetings are structured, planned, run and how decisions are recorded. I participate in regular productive meetings with Fedora Infrastructure.
I’ve always been an active person, through cycling and competitive dancing, and even as a student, I’m always thinking about how I can make things better for others. Thus, my current governance experience comes from outside of the open-source world, however, it translates well to the Fedora Project.
I’m an elected member of my school’s board and a member of the school’s parliament. I’m familiar with what it means to represent a diverse community, balance viewpoints, and make consensus-driven decisions. In this role, I dealt with issues such as financial disbursement and conflicting student choice.
As an independent contributor, my focus is entirely on serving our community and listening to the communities voice. While I respect the fantastic work of those who came before me, I will bring independent perspective to the Council, guided by my ethical commitment to fully open-source software.
To me, software freedom is a digital right.
What do you see as potential opportunities and risks for the Fedora Project?
When looking at the landscape now, the single biggest risk facing Fedora right now is the rush to implement AI everywhere. This threatens not only a drop in quality of our codebases but also creates massive legal grey areas. The community is rightfully pushing back against this. Fedora must refuse to let this hype dictate our governance.
The opportunity for Fedora is to set the global standard for what a measured, ethical, and secure approach to AI tooling looks like. Instead of rushing to adopt external, proprietary black boxes, Fedora should take its time to define how open-source principles apply, prioritizing local execution, strict licensing compliance, and open-weight models. Fedora can champion true open-source principles in a changing landscape, proving that innovation does not require the sacrifice of security or ethics.
Our priority must always be human craftsmanship and infrastructure integrity; any tool we introduce must serve our contributors, not replace them.
What brought you to the Fedora Project?
My first introduction to Fedora happened on July 20, 2025, when I sent an introduction to the infrastructure mailing list. On May 21, 2026, I was sponsored to my first sysadmin group. That is what Fedora has done for me and what I can do for Fedora.
Before joining the project, I was a sysadmin working completely alone. Fedora gave me the space to learn how to function in a bigger team, how to navigate complex infrastructure, and how to collaborate effectively.
My trajectory shows I’m capable of learning, adapting, and integrating into complex systems at an exceptional pace. I’ve gone from a newcomer to an active contributor, not only in the infrastructure team but also in Fedora Data Working Group, where I’m helping Hatlas come to life, and in the Join team, where I help new contributors find their footing.
Fedora has helped me scale up my skills rapidly, and I am running for council to ensure Fedora remains just as dynamic, rock-solid, and welcoming for everybody else.
This is a part of the Fedora Linux 44 FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.
Interview with Fabio Valentini (decathorpe)
FAS ID: decathorpe
Matrix Rooms: Too many to list them all: #devel, #rust, #epel, #multimedia, #pride, #python, #quality, #security, … (on the fedoraproject.org homeserver)
Questions
Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?
I have contributed to many areas of the project since I joined it over a decade ago, so I think I can bring a broad perspective to FESCo. I want to help insure the project’s continued success happens in a sustainable way.
How do you currently contribute to Fedora? How does that contribution benefit the community?
I am the most active package maintainer in Fedora (by count of updates / builds), primarily because I am the main point of contact for most Rust packages. My work includes package updates, package review, triaging build failures and broken dependencies, and pruning packages for obsolete, outdated, or unused Rust crates from Fedora. I regularly contribute to upstream projects through bug reports and pull requests to fix issues that are discovered downstream in Fedora. Additionally, I triage, report, and attempt to fix upgrade path issues caused by missing package updates every release cycle.
How do you handle disagreements when working as part of a team?
Many disagreements I’ve handled were only concerned with details, while the goals of everyone involved were still aligned. So I try to find common ground and / or explore alternative or creative solutions that can work for everyone involved.
Where do you think the Fedora Project should position itself concerning the use of ‘AI’ in software development?
I am – in general – wary of becoming dependent on products from companies that are nowhere near profitable and only kept afloat by a combination of inconceivably large amounts of venture capital and “creative” investment arrangements. Additionally, to me these “AI” systems aren’t “just tools” and can’t be treated solely as such, especially due to externalities like unethical data scraping practices, copyright / license laundering, excessive power and water consumption, noise and greenhouse gas pollution, hardware shortages and price increases, etc. I have yet to see a competitive “AI” product that does not have these problems, and I am unsure whether creating one is even possible.
What else should community members know about you or your positions?
This is a part of the Fedora Linux 44 FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.
Interview with Neal Gompa (ngompa)
FAS ID: ngompa (Conan Kudo is a common nickname for me)
Matrix Rooms: devel:fedoraproject.org, #asahi:fedoraproject.org, #asahi-devel:fedoraproject.org, #kde:fedoraproject.org, #workstation:fedoraproject.org, #cloud:fedoraproject.org, #kernel:fedoraproject.org #centos-hyperscale:fedoraproject.org, #budgie:fedoraproject.org, #multimedia:fedoraproject.org, #miracle:fedoraproject.org, #cosmic:fedoraproject.org, #centos-kernel:fedora.im, #admin:opensuse.org, #chat:opensuse.org, #bar:opensuse.org, #obs:opensuse.org, #RedHat:matrix.org, #networkmanager:matrix.org, #rpm:matrix.org, #rpm-ecosystem:matrix.org, #yum:matrix.org, #manatools:matrix.org, #lugaru:matrix.org, #buddiesofbudgie-dev:matrix.org, #PackageKit:matrix.org, #mir-server:matrix.org, #mageia-dev:matrix.org, #kiwi:matrix.org (There’s quite a bit more, but I think that sort of covers it. ) (There’s quite a bit more, but I think that sort of covers it. )
Questions
Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?
As a long-time member of the Fedora community as a user and a contributor, I have benefited from the excellent work of many FESCo members before me to ensure Fedora continues to evolve as an amazing platform for innovation. For the past few years, I have had the wonderful privilege of serving as a member of FESCo, and I enjoyed my time serving to steer Fedora into the future, and I wish to continue to contribute my expertise to help analyze and make good decisions on evolving the Fedora platform.
How do you currently contribute to Fedora? How does that contribution benefit the community?
The bulk of my contributions to Fedora lately are on the desktop side of things, though I have gotten back into doing core stack stuff too. Most recently, I’ve worked within the KDE community to help develop Plasma Login Manager and Plasma Setup to further modernize the Fedora KDE Plasma Desktop Edition and enable it to fully participate in the Fedora Ready program. I have also been actively assisting our friends at various PC makers participating in the Fedora Ready program to better support Fedora as an operating system offering for their products. This has directly led to the Fedora community gaining a new Fedora Ready participant with Star Labs, who offers Fedora KDE on their products as an operating system option. There’s always more to come on that front, and I hope Fedora Ready will continue to grow. On the core stack side of things, I’ve recently ported PackageKit’s DNF backend to DNF5, which once again unifies Fedora’s package management stack for the first time in several releases. This unlocks the ability for us to freely leverage DNF5 features that do not have analogues in DNF4.
My hope is that the work I do helps with making the experience using and contributing to Fedora better than it was ever before and that Fedora’s technical leadership in open source draws in more users and contributors.
How do you handle disagreements when working as part of a team?
I attempt to explain my viewpoint and try to build consensus through persuasion and collaboration. If there isn’t a path to consensus as-is, I try to identify the points of disagreement and see if there is a way to compromise to resolve the disagreement. Generally, this ultimately results in a decision that FESCo can act on.
Where do you think the Fedora Project should position itself concerning the use of ‘AI’ in software development?
I am rather conflicted about “AI” technology, especially LLM-based generative AI (GenAI) technology. I worry that it wipes out the implicit fairness that we believe Free Software carries. The nature of this tooling and how people gain access to quality tools creates an unpleasant classist split of haves and have-nots based on affordability. As the costs to access and leverage LLM technology skyrocket, a new underlying elitism will implicitly develop since only gainfully employed affluent developers will have access to the best technology.
It is true that there are open models under OSI licenses that exist (IBM Granite and Google Gemma 4 are examples of these), and I know that it’s possible to create your own models leveraging open source technology. But to date, open models do not yet produce results as good as the frontier proprietary cloud models, and we now operate in a world where proprietary services tightly integrate these things together and make it very hard to ignore the result. Perhaps more focused development on open models leveraging open source technologies will change that, but given how expensive such endeavors are, I am a little skeptical. Or perhaps the lack of willingness by many AI practitioners to pursue that is what makes me skeptical.
Putting that all aside, I am skeptical of AI technology in large part of my experience as an open source software maintainer. The quality of contributions are significantly lower than unassisted ones thus far (here’s a notable example), and while I’m sure it is possible to leverage it effectively in a productive fashion, there is mounting evidence that our ability to learn and maintain cognitive skills are weakened by reliance on AI technology as it exists today. I would prefer to receive poorer contributions from people that were their own as an opportunity to help them grow, because that is the embodiment of human success.
In the end, I do not feel like it is a good idea for Fedora as a project to make AI a critical pillar, but supporting open source, well-integrated tooling for people to experiment with AI/ML in the environment of their choice and knowing the risks they take on in doing so is perfectly fine with me.
What else should community members know about you or your positions?
To me, the most important thing about Fedora is that we’re a community with a bias for innovation. Our community looks to solve problems and make solutions available as FOSS, and this is something that Fedora uniquely does when many others take the easy path to ship old software or nonfree software everywhere. We work with tens of thousands of projects to deliver an amazing platform in an easily accessible and open fashion, built on FOSS infrastructure and tools. This makes Fedora special to me, and we should continue to hold ourselves to that high standard.
I’m also a big believer in community bonds and collaboration, which is why people tend to find me all over the place. I’m involved in Asahi Linux, CentOS, openSUSE, and several other similar projects in leadership roles as well as a contributor in order to demonstrate my commitment to this philosophy.
This is a part of the Fedora Linux 44 FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.
Interview with Simon de Vlieger (supakeen)
FAS ID: supakeen
Matrix Rooms: I am in many rooms but most active in the Release Engineering, ELN, bootc, Atomic Desktops, and my projects Image Builder channel.
Questions
Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?
In the past I’ve interacted with FESCo only through change proposals. Due to the nature of my work on image-builder I’ve gathered quite a bit of knowledge and ideas (though never enough) about the whole of Fedora and how it is put together. I’d like to take part in the other side of things both to learn more but also to apply what I have learned.
Personally I’m a big proponent of “building on Fedora”. By that I mean that we could and maybe should make Fedora as generic as possible in the packaging department with few assumptions about how an eventual system is laid out. This would open the road for more technical variety in the various editions, spins, and labs. Examples here (non-exhaustive) would be UKIs, systemd-boot, BTRFS boot-to-snapshot, and others.
Separately but interconnected is that I’d love it for Fedora to be the prime place people go to if they want to build their own flavour of a distribution. Remix culture should be nurtured, documented, and made as easy as possible so that the ideas can be tried and tested outside of Fedora before making their way into Fedora.
How do you handle disagreements when working as part of a team?
Well, I take a super pragmatic approach to disagreements. Sometimes it’s just easier to bow out of a disagreement than to continue it. Often times one person cares more about a given problem than another person and to me that means it can be good to give in, expecting the same in return on a later issue that another person might care more about.
This way fosters pretty strong ownership of problems and an environment where people trust eachother on problems rather than going at eachother.
Where do you think the Fedora Project should position itself concerning the use of ‘AI’ in software development?
Super hard question. Since this is specifically about AI in software development most of it would probably concern what upstreams do. As long as they keep compatible licenses we won’t have much of a say in this.
As for the more general approach to ‘AI’ in software development I feel like we should promote open implementations as far as that’s possible. The AI/ML SIG has been doing a lot of work with ROCm and other open stacks to be able to run models on Fedora. The future is not servitude to big tech companies but hopefully running our own local models.
There’s probably more that can be done in outreach as ‘AI’ stacks can be notoriously hard to package, our expertise could be shared and it might be useful; but I don’t know if that should/would be a Fedora Project kind of thing.
What else should community members know about you or your positions?
Firstly, I want to disclose that I work at Red Hat as people do hold opinions about that so let’s have that out of the way.
Other than that I want things to be open with the community deciding our direction. Generally I’m on the ‘conservative’ side as far as there is a conservative side in Fedora. I mean that in the sense that I think our current rules and guidelines concerning contribution and packaging are a decent starting point and we should not change them lightly.
We should also try to use as much as possible that what Fedora already offers. Many recent projects have been causing splits in infrastructure and community spirit. Let’s do less of that.
This is a part of the Fedora Linux 44 FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.
Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?
I have been active in the Fedora community since almost the very beginning (see also the next question), and an elected member of FESCo since the F40 election cycle. Outside of committee work, I am an experienced packager for multiple programming language ecosystems and maintain tooling intended to improve packaging workflows.
The project is facing some interesting decisions at the moment, in terms of what we produce (which packages, in what formats, for which architectures), how we produce them (what build systems, how we do quality assurance, especially in the face of an avalanche of CVEs), and who our contributors, users, and downstreams are. It needs both experienced hands who knows how things are done and why, as well as familiarity with current industry practices.
I believe I bring both of these to the table. At my day job, I focus on upstream distribution work and integrating improvements into our production fleet, which informs the perspective I bring to my FESCo work. If reelected, I hope to continue contributing that perspective – and I hope I have demonstrated my ability to separate what is best for the project from what is best for my employer.
How do you currently contribute to Fedora? How does that contribution benefit the community?
Apart from my FESCo membership, I am an active packager and a member of various packaging SIGs (Rust, Python, Golang). My day job revolves around a large CentOS Stream deployment, so I was a member of the Fedora EPEL Steering Committee, am an active member of the CentOS Hyperscale SIG, and co-founded the Proposed Updates SIG that is forked off to focus on producing timely updates for those who deploy CentOS Stream in production.
I maintain sandogasa, a set of tools and library crates to assist with Fedora and CentOS packaging workflows. They solve some unique needs (e.g. bootstrapping EPEL packages, both those needed at work and also those needed to run Fedora’s mailing list infrastructure), and sometimes provide up to date alternatives to previously-written utilities (e.g. sandogasa-hattrack can surface someone’s Fedora Discussions activity – a platform that was not around when fedora-active-user was written). As these tools mature I hope to see them adopted more as part of project workflows.
I have landed multiple change proposals in the past – most notably around Btrfs and systemd-oomd. Most recently, for the F43 cycle Neal Gompa and I worked on Wayland-only GNOME and for F44 cycle, I landed:
How do you handle disagreements when working as part of a team?
In my experience, disagreements are sometimes inevitable. While it is better to have consensus, sometimes that’s not possible, and it is important to recognize those situations and agree to disagree.
It is sometimes easier to understand each other’s positions in less formal situations – I am reminded of our Friends foundational value here. This is where having personal interactions with other community members really helps – we can disagree without taking things personally, or clear things up in a side channel because sometimes some reasons cannot be divulged in public.
In the end, we are all fallible humans, and we all have our own interests and preferences, both personal and work-driven. Being able to understand those we disagree with both make it easier to keep things civil and to find compromises.
Where do you think the Fedora Project should position itself concerning the use of ‘AI’ in software development?
I have a nuanced take on this, so this will likely rub some people the wrong way. I have strong ethical reservations about using (generative) AI, and legal reservations as well, but IANAL so I will not really cover the legal aspects here; I defer to all the legal counsels who have vetted the project’s AI policy and my employer’s legal counsel who must have OKed our AI usage…
Using AI in software development is, as a large project shipping mission critical software, sadly seems to be verging on inevitable these days – but I’d rather we use it defensively, like how curl uses AI scanners. Using it to help triage issues, like COPR’s Log Detective, is also promising.
We certainly could use some more resources when it comes to fixing CVEs and when it comes to tooling – there are simply not enough volunteers, sadly. Though – this comes up in Debian’s debate about AI usage too – we should be careful not to close off opportunities for new contributors because it’s easier to fix something with LLM assistance than to onboard someone to do it.
I will own up to writing sandogasa mostly with AI assistance. As part of that, I wrote up my personal LLM policy for those curious. As the org name (slopfest) suggests, my colleague and I who have repos there feel conflicted about the use of LLMs; we try to limit it to this GitHub organization, and to tasks that are repetitive and error-prone anyway. Just as artifacts produced by GNU autotools do not need to be GPL licensed, hopefully you can use these tools free of any LLM taint.
Finally, the elephant in the room – the Fedora AI Developer Desktop Initiative, that intends to make it easier to install hardware drivers and development libraries needed to leverage GPUs, including, controversially, the proprietary NVIDIA stack. NVIDIA is worth over USD 5tn. IBM is valued at just over USD 200bn. I think NVIDIA can hire enough people with packaging experience to solve the problems they themselves cause by not open sourcing key headers people want to compile against – and I know they do employ people who know packaging. I think one role distributions like Fedora can do, and large NVIDIA customers especially among the hyperscalers, is to have a common position to negotiate with NVIDIA. If that happens then we might have enough traction to end up with positive outcomes.
Without pushing back against the tide of AI boosterism, I fear that the reputational damage because this is seen to be a top-down initiative would outweigh any benefit – and I still think this could have been a remix and Council was involved unnecessarily early. We used to be perceived as caring strongly about licensing (it took us a long time to ship a subset of RPM Fusion, and Tom Callaway’s work is immortalized in the name of Fedora’s previous licensing system), and I really prefer that we’re not seen to be AI boosters, because a) it does not seem like the right thing to do IMHO and b) the crowd we will attract, and likewise, the existing contributors and userbase we will alienate.
What else should community members know about you or your positions?
I work for Meta – which runs CentOS Stream on millions of bare metal servers and in containers. I hope I have demonstrated over the past two years in FESCo, and over a longer period in my other Fedora and CentOS engagements, that I try to put the community first and not let my employer’s interest override my responsibility to the community.
I recently relocated to Ireland with my wife and kid – it’s a lovely country, and a fascinating bridge between the US we left and Europe, given the presence of US multinationals here and the history of Irish emigration. We are looking forward to attending more European open source conferences in the future once we are more settled in.
This is a part of the Fedora Linux 44 FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.
Interview with Maxwell G (gotmax23)
FAS ID: gotmax23
Matrix Rooms: Fedora Devel, Fedora Golang, Fedora Python, and I loiter in a bunch of other places!
Questions
Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?
I care a lot about Fedora, and I hope to bring a fresh voice to FESCo informed by my multiple years of active participation in Fedora development. I want Fedora to continue to excel as a Linux distribution and a FOSS community that is welcoming to new users and contributors and ideas. I value the Fedora Foundations and the long-term contributors that have built a great distribution and improved our upstreams and the FOSS community at large.
Additionally, I am interested in ensuring the day-to-day aspects of Fedora development run smoothly and continuing to improve the packager experience. I am closely watching upcoming changes to dist-git (and potentially bug-tracking) in Fedora. I am excited about these changes — this is a great opportunity to address warts with the existing systems — but it is crucial to ensure that the transition fully addresses the project’s needs.
How do you currently contribute to Fedora? How does that contribution benefit the community?
I am part of the Golang and Python SIGs and the FPC and have worked a lot on Packaging Guidelines improvements and RPM automation (macros, generators, etc.). As a FESCo member, I would continue to guide workflow improvements in Go, Python, Ansible Collections, and beyond. We’ve made good strides, but we still have work to do, especially surrounding multi-build updates, mass rebuilds, security bugs, and license detection.
I run the Orphaned Packages Process and maintain the associated tooling. I am also a packager sponsor and have mentored a couple new Fedora contributors. I will continue keeping the Fedora package collection healthy and helping new people get involved in Fedora development as a member of FESCo.
I maintain the Ansible stack in Fedora which led me to work upstream on the Ansible Community Steering Committee and the release manager team.
How do you handle disagreements when working as part of a team?
One of my favorite parts of FOSS communities like Fedora is getting to work with so many passionate people from all over the world toward a shared goal. I think it’s important to keep this is mind when having disagreements. Disagreements happen, but we can always create room for respectful dialogue and compromise. In the end, we are all on the same team.
Where do you think the Fedora Project should position itself concerning the use of ‘AI’ in software development?
I am an AI skeptic and worry about AI’s impact on society, the environment, and human intellectual creation. But I understand that various industries, including ours, are (attempting to) adopt AI-based tools. Just recently, I reviewed a set of AI-assisted contributions to a Fedora package. I am still trying to balance these conflicting notions. I am willing to support AI experimentation based on free/open technologies in Fedora as long as our project’s principles and policies are followed and the community is on board.
This is a part of the Fedora Linux 44 FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.
Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?
I am a long time Fedora user and contributor, with my first contribution dating back to 2008. Having previously served as a member of FESCo from 2015 to 2018, I understand the gravity and operational realities of this committee. My foundational engineering roots in the project include serving in SysAdmin Main within the Fedora Infrastructure Team and working as a member of the Fedora Release Engineering Team, where I contributed to our core build tooling, container infrastructure, and Project Atomic. Additionally, I spent roughly a decade upstream as a member of the Ansible Core Engineering Team, driving various Fedora focused integration efforts.
What I hope to bring to FESCo this time around is a pragmatic, deeply experienced perspective on how we can responsibly bring AI technologies into both the inner workings of Fedora as a project, and into the deliverable artifacts we release to our users. My goal is to ensure this transition happens safely, securely, and in absolute alignment with the open source way.
How do you currently contribute to Fedora? How does that contribution benefit the community?
I have recently re-engaged my hands on contributions, focusing primarily on AI related projects and working to scale my contribution footprint back to my historic levels. Even with a multi year hiatus, my historical contributions still ranks me in the top 50 of all contributors in the Fedora Badge System. Over my career, I have contributed to more than 200 open source projects, many of which remain packaged and shipped in Fedora today. My current work aims to ensure Fedora stays ahead of the curve as the landscape shifts toward AI native software stacks.
How do you handle disagreements when working as part of a team?
I always aim to find consensus through collaborative discussion, transparency, and healthy, respectful debate. I believe a steering committee’s job is to weigh technical merits and community impact objectively. However, if a consensus cannot be reached and a majority vote is taken, I fully practice the principle of “disagree and commit.” Even if a decision goes against my personal vote, I will actively support and work to successfully execute the majority decision to keep the project moving forward smoothly.
Where do you think the Fedora Project should position itself concerning the use of ‘AI’ in software development?
Fedora needs a pragmatic open source strategy to address AI’s disruptive impact on both the software development ecosystem and open source itself. We must establish clear, principles based guardrails around the ethical use, consumption, and application of AI within our project’s development pipelines, while continuously solidifying Fedora’s core principles of The Four Foundations, in a rapidly changing world. We should position Fedora not as a passive consumer of industry hype, but as the secure, foundational infrastructure that makes open source AI development possible.
When it comes to AI in software development, my position centers on two fronts:
Infrastructure & Tooling: Fedora must excel at providing the open source building blocks, runtimes, and container environments required to build, test, and serve models locally and securely. We need to ensure our developer tooling adapts to modern workflows while fiercely protecting user privacy and data sovereignty.
Security, Sandboxing, & Provenance: As AI assisted code generation and autonomous agentic tools inevitably find their way into development pipelines, FESCo must proactively advocate for strict isolation, predictable build environments, and robust supply chain security. We must ensure that automated code contributions or AI developer aids do not introduce unvetted security vulnerabilities, malicious packages, or license compliance risks into the Fedora ecosystem.
What else should community members know about you or your positions?
I have been an open source contributor for more than 25 years. Professionally, I am a Distinguished Engineer at Red Hat. In my open source community efforts, I serve as the TAC Chair of the LF AI & Data and am an active upstream core maintainer of OpenShell. I have previously had the distinct honor of serving the Fedora community on FESCo, and I would be incredibly grateful for the opportunity to bring my combined history in Fedora and my current expertise in AI systems back to the committee to help steer our next chapter.
This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infrastructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.
Week: 25 – 29 May 2026
Fedora Infrastructure
This team is taking care of day to day business regarding Fedora Infrastructure. It’s responsible for services running in Fedora infrastructure. Ticket tracker
This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure. It’s responsible for services running in CentOS Infrastructure and CentOS Stream. CentOS ticket tracker CentOS Stream ticket tracker
Greg continues to hold the fort as well as possible
Another mirror request in progress
Stream mirror sync seems to have caught up from its slowness last week
SELinux issue in the Stream GitLab runners, debugged and restored with S.Gallagher
Many Let’s Encrypt SSL certs due for renewal, currently in progress
Release Engineering
This team is taking care of day to day business regarding Fedora releases. It’s responsible for releases, retirement process of packages and package builds. Ticket tracker
Fedora 42 will reach END OF LIFE on Wednesday, May 27th, 2026
RISC-V
This is the summary of the work done regarding the RISC-V architecture in Fedora.
F44 rebuild: 99% of it is done
Blocker now unblocked: A large Qt 6.11 update (500+ packages) is in progress, which was previously blocked by qt-webengine. The necessary patches have been rebased, so the update can now proceed.
Cloud and server images are unblocked. Still need to do the kiwi-descriptions; in progress
Currently short on time due to various resource constraints.
Hardware
An additional P550 board has been added to the Fedora RISC-V build farm
Sorting out the process to procure two K3 units for Fedora RISC-V Koji builders.
Migrating from Forge: plans to migrate the secondary dist-git overlay to forge.fp.o/riscv
This team is taking care of quality of Fedora. Maintaining CI, organizing test days and keeping an eye on overall quality of Fedora releases.
More and better docs, continued tech debt repayment and app improvements, openQA ELN coverage enhancement and start on cycle upgrades, also see items in AI section above
We’ve created a Guides & How-Tos category for Fedora Quality Docs, and try to populate it with useful articles. More will come.
openQA stuff: extended ELN coverage, upgraded staging to Fedora 44, updated os-autoinst to latest upstream on staging, discovered a weird bug that needs working out before going to prod
Forgejo
This team is working on introduction of https://forge.fedoraproject.org to Fedora and migration of repositories from pagure.io.
Move Fedora Badges static assets from Pagure to Forgejo [Followup]
A year ago, a family member gave me a 2019 laptop that wouldn’t run Windows anymore. And of course, I immediately installed Fedora Linux on it. While my day-to-day Fedora Linux system is a desktop PC, it’s nice to have a laptop to take with me when I do workshops or conference demos.
However, the laptop has a physical “spinning heads” hard disk, so it is really slow to boot. I timed it; the laptop takes almost two minutes to go from “power on” to “login prompt.” And that’s a very long time when you’re at the front of the room, waiting to start a demo.
I thought about replacing the hard disk with a solid state drive, but when I opened the laptop to make sure the drive was replaceable, I saw that the laptop also supports an NVMe solid state drive in addition to the hard disk.
This presented an interesting opportunity: I could put in an NVMe drive and install Fedora Linux across two disks. Specifically, I wanted to boot Fedora Linux from the NVME drive, and keep extra apps and other data on the hard disk. I use several big third-party apps for my demos, which I install in both /opt and /usr/local, and it’s a huge pain to download and install those extra applications whenever I upgrade Fedora Linux. (I prefer to wipe and reinstall when I upgrade Fedora Linux, so I always have a clean starting point.) If I could keep /opt and /usr/local on the hard disk, I could preserve those when I install the next version of Fedora Linux.
Installing Fedora Linux to the NVMe
After installing a new NVMe drive in the laptop, I needed to reinstall Fedora Linux. I prefer the Xfce desktop, so I downloaded the Fedora Xfce spin and booted the installer. When the installer reached the “Destination” step, it prompted me for the target disk. I clicked “Choose destination” and selected the NVMe disk:
The rest of the installation ran normally. The Fedora Linux installer set up the partitions automatically on the new NVMe drive, encrypted my data, and installed the operating system.
With Fedora Linux on the NVMe drive, booting took seconds instead of minutes. Again, I timed it: about 20 seconds to go from “power on” to “login prompt.” That’s a huge improvement!
Setting up partitions on the hard disk
The disk partition app in the Fedora Xfce is GParted, which makes it easy to set up the hard disk with new partitions. However, GParted’s main limitation is that it can’t set up encrypted volumes for you. If you want to use encryption, you’ll need to use the command line and run cryptsetup on your own.
However, I’m not very concerned about encrypting my /opt and /usr/local partitions. These are just third-party apps, not private data. My personal data will be saved to my home directory, which is safely encrypted on the NVMe drive. So I decided to set up regular partitions, formatted as ext4 filesystems.
I used GParted to delete the old partitions on the hard disk, and define three partitions that were each about 300 GB: /opt (which I labeled as opt), /usr/local (labeled usrlocal) and /backup (labeled backup). GParted created the partitions and wrote an ext4 filesystem on each.
However, the /usr/local filesystem has a directory tree in it already, such as /usr/local/bin and /usr/local/lib, although these directories will be empty after installing Fedora Linux. I wanted to copy the original directories to the new filesystem. The easiest way to do that is to add the new usrlocal partition somewhere else and then copy the old /usr/local to the new partition. Adding a partition to a directory is called mounting, and the directory itself is called a mount point.
First, I needed to create a new mount point for the usrlocal partition, which can be located anywhere on the filesystem. Since this was temporary, I created it under /tmp then mounted the new partition using the mount command:
$ sudo mkdir /tmp/usrlocal
$ sudo mount LABEL=usrlocal /tmp/usrlocal
Then I copied the contents of the old /usr/local to the new /tmp/usrlocal mount point. The -a or –archive option copies everything:
$ cd /usr/local
$ sudo cp --archive * /tmp/usrlocal
After the process is complete, I unmounted the new partition:
$ sudo umount /tmp/usrlocal
Adding the partitions to the system
To make sure the new partitions are automatically mounted every time my laptop reboots, I needed to add them to my /etc/fstab file. This is a special file that contains the filesystem table, which is a list of partitions that the system can find on the disk and where to mount them. For example, my default /etc/fstab file looks like this:
#
# /etc/fstab
# Created by anaconda on Sat May 23 20:15:13 2026
#
# Accessible filesystems, by reference, are maintained under '/dev/disk/'.
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
#
# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.
#
UUID=c10ec138-be4b-4513-89b7-749ef4a0605e / btrfs subvol=root,compress=zstd:1,x-systemd.device-timeout=0 0 0
UUID=a87b1ed4-4951-4da1-a4a4-a5c48f1f3b28 /boot ext4 defaults 1 2
UUID=9AD9-2C52 /boot/efi vfat umask=0077,shortname=winnt 0 2
UUID=c10ec138-be4b-4513-89b7-749ef4a0605e /home btrfs subvol=home,compress=zstd:1,x-systemd.device-timeout=0 0 0
Each line in the /etc/fstab file is divided into several fields: the identifier for the filesystem (to learn more about these, see Persistent Identifiers for Storage Devices in the Fedora online documentation), the mount point, the filesystem type, a list of mount options, and two optional fields that control if backup software should “dump” the filesystem to backup media (use 0 for never) and what order the fsck command should check filesystems when needed (usually 1 for the root filesystem, or 2 for other filesystems). I added these lines to my /etc/fstab file, which defined the mount points for each of my new filesystems:
This is an internal drive, so it should be there every time the laptop boots up. If you add removable storage to the /etc/fstab file, such as a USB drive, you should add the nofail option to this list of mount options. Otherwise, if the partition is not available when Linux starts up, the system will hang.
With these lines in the /etc/fstab file, I ran these commands to reload the /etc/fstab file, create the /backup mount point, and mount each of the filesystems:
$ sudo systemctl daemon-reload
$ sudo mkdir /backup
$ sudo mount /backup
$ sudo mount /opt
$ sudo mount /usr/local
This generated an SELinux alert right away, complaining that the new /usr/local filesystem lacked the correct security context. The security information wasn’t “carried over” when copying the old /usr/local directory tree. Fortunately, the SELinux error provides the solution:
To restore the default SELinux security contexts to the new /usr/local directory tree, I ran the restorecon command. The -v option will print what it does to fix the system:
$ sudo restorecon -v /usr/local Relabeled /usr/local from system_u:object_r:unlabeled_t:s0 to system_u:object_r:usr_t:s0 Relabeled /usr/local/lost+found from system_u:object_r:unlabeled_t:s0 to system_u:object_r:usr_t:s0
Filesystem flexibility
With just a few extra steps, I was able to use two disks with Fedora Linux, which lets me take full advantage of the storage on my laptop. The operating system now runs from the very fast NVMe drive, while my big third-party applications in /usr/local and /opt run from the hard disk.
This edition spanned over two days of the weekend, starting early Saturday at 09:00 and ending on Sunday at approx. 17:00. The schedule contained 16 talks on the main track, as well as 4 extra talks on a Python side-track and 3 workshop sessions, plus a round of lightning talks right before the closing ceremony.
The Fedora Project was one of the sponsors of this year’s edition, providing some branded cups — which were given out as prizes for asking good questions in after-talk Q&A — as well as a catering budget.
The Fedora community was represented by Dominik Mierzejewski and Artur Frenszek-Iwicki. Dominik held a workshop session where he talked about video acceleration on Linux and helped the attendees set up their systems to make best use of their hardware.
“It’s actually weird. 10 years ago I’d have a lot to do, but now, people come over to the workshop and it turns out everything just works.” — Dominik
One of this year’s sponsors, Korbank, ran a contest where the attendees could try their best at assembling a rack server: inserting the power supplies, disks, memory and the CPU. The whiteboard tracking the scores revealed a truly fierce competition: while the first contestants barely made it under 2 minutes, the final winner finished well below 50 seconds!
There was also a community stall ran by the Coreforge Foundation, showcasing their progress in developing open hardware RISC-V CPUs. Pictured above is an FPGA programmed to run one of the foundation’s RISC-V cores.
No community meetup can be complete without a big bunch of stickers to share and give away — and this event was no different, featuring two tables full of stickers, posters and postcards, generously provided by the Free Software Foundation Europe and the NGI Zero fund.
This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infrastructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.
Week: 18 – 22 May 2026
Fedora Infrastructure
This team is taking care of day to day business regarding Fedora Infrastructure. It’s responsible for services running in Fedora infrastructure. Ticket tracker
Badges: Include deployment controls for Fedora Infrastructure [Commit]
Badges: Refactor/get persons by nickname pagination [Approved]
Badges: Add get_badges_by_string method with pagination [Suggested]
Badges: Include unit tests for the _serve_frontend function path [Triaged][Followup]
Badges: WIP: Move the Fedora Badges static assets from Pagure to Forgejo [Commit]
Nagios is down to < 100 items, it’s nearly gone!
CentOS Infra including CentOS CI
This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure. It’s responsible for services running in CentOS Infrastructure and CentOS Stream. CentOS ticket tracker CentOS Stream ticket tracker
Mostly business as usual, just trying to cover the basics
New mirror request completed, some hosts needed reboots/pokes
Watching the CVE storm, mitigating exposed hosts, and waiting for kernels to reboot on
Release Engineering
This team is taking care of day to day business regarding Fedora releases. It’s responsible for releases, retirement process of packages and package builds. Ticket tracker
Continued reviewing releng change proposal for f45 changesets
Continued working for introduction of differentiation in beta and final variants in composeinfo file according to standards.
RISC-V
This is the summary of the work done regarding the RISC-V architecture in Fedora.
F44 rebuild: 22K packages built out of 24K.
Continued with benchmarks on remote SpacemiT K3. (The access will expire in a couple of days.)
Continued preparing the Flock presentation.
Fedora Koji builder hardware: Wrote a brief business justification for two units of K3 for Jason and David.
Debug a failed OpenJDK build, fix the bug, and kick off a fixed up build. Kicked off a fixed up JDK main build
QE
This team is taking care of quality of Fedora. Maintaining CI, organizing test days and keeping an eye on overall quality of Fedora releases.
Published Fedora Quality contributors statistics for the Fedora 44 cycle
Our remarkable Fedora ambassador, CentOS, and associate crews delivered live face-to-face support and outreach via our Fedora and CentOS @ SCALE 23x Linux Conference.
Welcome to SCALE! – Photo by @lajuggler
This way to registration… – Photo by @carlwgeorge
TL; DR
What: A community-run open-source and free software conference in Pasadena, California
The SCALE (The Southern CAlifornia Linux Expo) 23x community Linux event encompasses the 23rd Linux and related technology event with four days of exhibits, tutorials, and demos. This year’s SCALE happened in Pasadena (Los Angeles) area.
SCALE attracted about 3,000 worldwide guests to discuss Linux, AI, DevOps, security, free and open-source software, and more. Technical Committee (Online Services) Chairperson, Mr. Phil Dibowitz, and Network & Wifi Chairperson, Robert Hernandez, among many other community volunteers paved the way for a smooth registration.
Expo Highlights
Our Fedora Community Architect @jflory7 curated and arranged delivery of key swag and marketing items to Perry Rivera. Items included: commuter mugs, buttons, pens, stickers, badge lanyards, and more.
Day 0: Wednesday 4 March
Ahead of our event, Fedora Contributor @chris furnished our attendees an amazing SCALE 23x Attendee badge. 58 attendees claimed the badge this year; cheers to @bcotton for being the first earner!
Fedora Ambassador @vwbusguy helped retrieve half of the items needed for the expo for next-day delivery.
Red Hatter and Fedora Ambassador @lajuggler later that evening delivered expo items.
Dry-board markers and flipchart easel
More swag
Rolling case
@lajuggler finalized Fedora setup on 2 laptops.
Meanwhile, the rest of the crew commuted and checked in.
Day 1: Thursday 5 March
@lajuggler attended an early morning Meshtastic workshop.
Ambassadors arrived to the expo floor to pre-setup booth tables and banners.
@carlwgeorge and @nimbinatus unpack project brand items. Photo by @aacosta
Booth setup v1 – Photo by @carlwgeorge
After @lajuggler ‘s workshop, he arrived later to the expo floor to join pre-setup and unpack swag, easel and markers, and a Fedora retromodem demo.
Welcome to Fedora Hatch Day. – Photo by @carlwgeorge
@jflory7 presents “The Fedora Docs Revamp: Building the Docs You Want to Read.” Photo by @carlwgeorge
@nimbinatus presents “A Brief Tour of the Age of Atomic.” – Photo by @carlwgeorge
@Dcavalca presents “Accelerating CentOS with Fedora.” – Photo by @carlwgeorge
A set of us departed for lunch so we could make ready for opening the Expo floor later that day. @lajuggler and @carlwgeorge set up live demos on both systems for guests to use.
Like to set this up? Get started with a presentation from @lajuggler here.
Retromodem demo by @lajuggler. Photo by @jflory7
Retromodem demo by lajuggler. Photo by lajuggler
Star Wars ASCIImation on retromodem demo by @lajuggler. Kudos to @spot for the find. Photo by @carlwgeorge
Retromodem demo by lajuggler. Photo by @vwbusguy
Retromodem telehack demo by lajuggler. Photo by @vwbusguy
Later that evening, we had dinner at El Portal. Moreover, Rob McBryde organized a stellar Karaoke night event at Barney’s Beanery.
Dinner at El Portal. Photo by @jflory7
@Rmcbryde wowed us with amazing karaoke covers. – Photo by @lajuggler
@lajuggler delivers a Toad song. – – Photo by @aacosta
@ichavero sang awesome memorable covers and engaged audience participation. – Photo by @lajuggler
Day 3: Saturday 7 March
Next, Our crew re-assembled in the expo hall to continue meeting and discussing with community. Later that evening, we had dinner and then converged on Game Night.
Enjoyed dinner at The Stand with friends. Photo by @jflory7
Game nite security was pretty extreme! Photo by @carlwgeorge
@carlwgeorge, @vwbusguy, Autumn Nash, Eric Hendricks. – Photo by @carlwgeorge
Photo by @carlwgeorge
Photo by @carlwgeorge
Day 4: Sunday 8 March
Once again, our crew gathered in the convention hall to continue our demos and greets with community. Later that afternoon, the crew packed up and closed the booth.
@vwbusguy and @aacosta serenade the space
@vwbusguy and @ichavero rockin’ out at the booth. Photo by @carlwgeorge
@vwbusguy and @ichavero rockin’ out at the booth. Photo by @aacosta
#CentOS – photo by @carlwegeorege
#Fedora – photo by @carlwegeorege
#leftnotrace Photo by @aacosta
Key Sessions and Takeaways
Session 1: Workshop: Long range, cheap comms through Meshtastic
Takeaway
Relevance to Our Work
Encourages communication with others
Encourages community
Relatively low cost to get started. Does not require a license
Minimal barrier to entry
Open-source
Encourages open-source activities
Physical component and light building assembly
Fairly easy to get started to communicate right away
Demo 1: WiFi Retromodem on Fedora 43 Highlights
Takeaway
Relevance to Our Work
Guests drawn by retro and novelty aspects of the retromodem and coolretroterm
Guests not normally interested in Fedora were happy to download a free PDF to learn how to build a similar setup at home with Fedora.
There was the concern that 9600 bps max would be too slow for guests, but people seemed perfectly fine with text whizzing by onscreen relatively quickly
Conversations would dovetail discussions in the CentOS side of the booth and vice-versa. This synergy brought in various guests and their associates for various reasons, encouraging the community aspect.
From start to finish, Fedora booth visitation highly visited
Fedora Hatch Day sessions were well attended. Most of the morning sessions appeared full or near full. Definitely must have for SCALE 24x.
Standing banners could be revised to include an easy to get to website and clear QR code
Fedora Account creation and badge claiming could be an easier process. It takes about 15-20 minutes just to set one up. Could this process be reviewed and possibly streamlined?
Do users running Fedora 2 revs below current get regularly reminded to update to prevent adverse security issues?
Our Fedora and CentOS Booths
@lajuggler and Kyle
@lajuggler, Bala, and Ilan
The awesome crew at Valkey
@lajuggler and @bcotton
@paradoxguitarist and @jflory
@lajuggler
@carlwgeorge
@lajuggler and Siggy
Our Fedora Booth
@spot and @lajuggler
Kubernetes in a backpage project
@lajuggler and Thomas
Dessert at game night had a strong Tux vibe
@lajuggler and Arthur
Lanyards and pens
@lajuggler and Jerry
Carlos Meza
Ilan
Mark Russinovich
@carlwgeorge
@davdunc and @lajuggler
@lajuggler and Phillip Banks
@lajuggler and Arian
@lajuggler and Jeff
Doug Comer
@lajuggler and Doug Comer
We had a fantastic turnout of about 3,000 Linux guests and a stellar Fedora Hatch Day.
A huge thank you to:
All Speakers: For sharing your expertise and time with the community.
All Volunteers: This event wouldn’t have been possible without the folks who managed the booths, and logistics.
Introduction Earlier this year, the community was invited to share their thoughts on a potential new initiative called “Fedora Verified“. The goal of this survey was not to make final decisions, but to listen – to understand what contributors value, where opinions differ, and what questions still need answering.
This is a summary of what we found.
Note: Fedora Verified is still a conceptual idea under discussion by the Fedora Council. Nothing has been finalized. The Council plans to continue these conversations with the community in the coming months, including at Flock.
Who responded?
The survey received 90 fully completed responses from contributors across the Fedora community. We focused our analysis exclusively on these full responses to ensure we are looking at complete, thoughtful feedback.
What the community said
Key Takeaways – When we looked at the data, a few incredibly clear themes emerged regarding what contributors want this program to look like if it moves forward:
Code isn’t everything: This was the loudest piece of feedback. A massive 66% of respondents explicitly stated that all types of contributions – including documentation, design, event organization, and community support – must carry the exact same weight as code contributions.
Keep the door open for newcomers: Nearly 40% of respondents expressed concern that adding a “Verified” status might intimidate new contributors and make it harder for them to get started. Any future model needs a welcoming, clear on-ramp.
12 months is too short: We proposed that the Verified status would expire after 12 months of inactivity. A majority (52%) rejected this, feeling that life gets in the way and a 12-month expiry is too strict.
Show us our progress: To help navigate the path to becoming Verified, 53% of respondents asked for a visual contribution tracking dashboard (similar to an enhanced Fedora Badges experience).
The Tension: Structure vs. Flexibility
The results also reveal two interesting and contrasting groups within the community regarding governance of the program.
A notable portion of contributors expressed a desire for more rigidity, wanting clearly defined milestones (43%) and formal committee reviews. At the same time, a similarly sizable group preferred less structure, with 62% asking for a moderately or lightly structured path, feeling that too much formality could discourage participation.
This tension was one of the most valuable findings of the survey. It shows that the Fedora Verified concept touches on something the community feels strongly about in different directions. Both perspectives are valid – setting clear expectations while leaving room for diverse contribution styles. The Council must achieve a careful balance as it moves forward.
What comes next?
These findings are being shared with the Fedora Council and relevant SIGs to inform future community conversations. The full analysis report, including a detailed breakdown of all survey responses, is available here: “Analysis Report.”
If you have thoughts or feedback on these findings, we’d love to hear from you on “Fedora Discussion.”
This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infrastructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.
Week: 11 – 15 May 2026
Fedora Infrastructure
This team is taking care of day to day business regarding Fedora Infrastructure. It’s responsible for services running in Fedora infrastructure. Ticket tracker
This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure. It’s responsible for services running in CentOS Infrastructure and CentOS Stream. CentOS ticket tracker CentOS Stream ticket tracker
This team is taking care of day to day business regarding Fedora releases. It’s responsible for releases, retirement process of packages and package builds. Ticket tracker
Fedora Release Engineering focused this week on Fedora 44 post-release stabilization, compose tooling improvements, and ongoing Forgejo migration work. The team also continued Fedora 45 coordination, infrastructure cleanup, and automation enhancements to improve operational reliability and reduce technical debt.
Completed Fedora 44 post-release cleanup and stabilization work
Reworked failed compose cleanup tooling to support Forgejo and remove remaining Pagure dependencies
Managed and updated the current RelEng sprint board
Continued Fedora 45 tracking and coordination work
Progressed ongoing migration and infrastructure modernization tasks
Assisted with maintainer processing and cleanup workflows
Investigated compose metadata handling improvements for Beta/RC/Final differentiation
Coordinated on ELN and Rawhide related operational issues
RISC-V
This is the summary of the work done regarding the RISC-V architecture in Fedora.
F44 rebuild: it’s almost done—less than 2K packages remaining (big credit to David here). Transition from CMake 3 to 4 and a couple of other solvable issues are causing some delays, but things are moving.
Work with a developer at a hardware vendor (SpacemiT) to get a 3-week access to RVA23 machine.
Study the hardware, documentation
Jason from Red Hat is looking to integrate K3 kernel support into Fedora “omni” kernels.
Started doing benchmarks of heavy-duty packages such as kernel, LLVM, glibc, QEMU and more. Details in this ticking ticket.
We’ll share these comparative at Flock RISC-V update
Explore a potential demo at Flock, logistics permitting
Debugged and found the root cause of a kernel build failure on RVA23 hardware
Work with Matthew to get two units of K3 hardware to be shipped for David (Meta) and Jason (Red Hat) for Fedora Koji builders
Analyzed the root-cause of an ‘io_uring’ error in ‘nbdkit’ with Rich and Andrea.
QE
This team is taking care of quality of Fedora. Maintaining CI, organizing test days and keeping an eye on overall quality of Fedora releases.
dirtyfrag update scramble, Podman test days, ongoing “quiet time” work: openQA test dev, ELN collaboration and test enhancement, tech debt repayment
Another fun branded kernel CVE scramble – got dirtyfrag updates tested and released within hours after submission
Uncovered a regression in GNOME Software potentially causing users (under certain conditions) to see a lower frequency of system updates delivery/notification. Fixed the regression together with the developer.
openQA test dev: gnome-initial-setup test merged and in production, Silverblue installer build test ported to image-builder to match prod, ongoing smaller fixes/improvements
ELN work: collaborating with yselkowitz and jforbes to try and get independent gating of ELN kernel updates, ongoing work on making rmdepcheck work correctly on ELN, adapted openQA tests to changes in ELN release packages, reported several notable bugs
The last few weeks have seen a significant spike in reports of security vulnerabilities in the Linux Kernel. CopyFail, DirtyFrag, and Fragnesia have all exposed a path for a malicious user to escalate their privileges on a system from a standard user to root, and it’s possible there are more vulnerabilities that will be found. The Fedora Project is committed to keeping its users secure and patched against vulnerabilities as quickly as possible when they are disclosed, so let’s talk about how we try to do that.
Recent developments in machine learning have lead to a veritable gold rush for security researchers who can now rely on LLMs to analyze massive code bases like the Linux Kernel and find vulnerabilities at a rate well above what was previously possible. LLMs are also being used to weaponize these vulnerabilities once they’ve been found, allowing attackers to significantly shorten the gap between vulnerability disclosure and exploitation in the wild (source). All this means that it’s more important than ever for Fedora to have a robust process for tracking these vulnerabilities and distributing fixes for them.
What Fedora is doing
There are a number of ways the Fedora Package Maintainers get notified of new security vulnerabilities, the simplest of which is through security bulletins. Many projects post about their security updates on places like the oss-security mailing list and several Fedora contributors monitor these mailing lists for relevant vulnerabilities. The Red Hat Product Security team will also often raise Bugzilla bugs against Fedora packages for CVEs they are tracking, allowing Fedora to take advantage of the work being done to support RHEL customers.
Often security updates will flow through the usual Fedora package update process. Fedora uses tools like Anitya and Packit to monitor for new releases of upstream packages and automatically prepare updates for them. This automation helps across all updates with achieving Fedora’s “First” foundation, but they’re especially helpful for security updates which can be extremely time-sensitive to publish. If everything works as designed, by the time a human gets involved in preparing the update, there could already be a pull request and scratch build ready for testing.
Once the Fedora Package Maintainers are aware of a security vulnerability in a package we distribute, we’ll evaluate the best way to make the patch available to users of supported Fedora releases. Often this just means publishing the latest version of the package, but sometimes this isn’t possible. If the fix has not yet been merged in the upstream project (as happened with the recent kernel vulnerabilities) or if the latest version is too far from the current package version in that Fedora release (more information), the fix may be applied as a standalone patch. This can lead to a situation where a fixed version of the package is available but the version number still shows the vulnerable version, so you can use the dnf changelog command to check the update history for the package and see if a patch has been applied.
Keeping your system secure
It may sound cliché, but for most users the best thing you can do to keep your system secure is regularly updating it. Security package updates in Fedora are tagged with their severity and CVE numbers, so you can keep track of when security updates are published into Bodhi (for example). You can also apply all the pending security updates on your system using the following command:
dnf update --security
Some desktop environments will proactively notify users if there are pending security updates for their system. For example, GNOME Software will periodically check for pending updates and send the user a toast notification like the one below prompting to install the updates.
If you’d like to automate patching vulnerable packages, dnf-automatic can be configured to automatically download and apply security updates on a schedule, although applying kernel upgrades will require rebooting the system. You can learn more about this in the documentation here.
Getting involved
If this kind of Open Source security sounds interesting to you, why not consider becoming a Fedora contributor? We’re always looking for more people to get involved with projects like the Security SIG and Kernel Maintenance!
This period is open until Thursday, 2026-05-21 at 23:59:59 UTC.
Candidates may self-nominate. If you nominate someone else, check with them first to ensure that they are willing to be nominated before submitting their name.
Nominees do not yet need to complete an interview. However, interviews are mandatory for all nominees. Nominees not having their interview ready by end of the Interview period (2026-05-28) will be disqualified and removed from the election. Nominees will submit questionnaire answers via a private Pagure issue after the nomination period closes on Thursday, 2026-05-21. Either the interim F44 Election Wrangler (Justin Wheeler) or the Fedora Operations Architect (Aoife Moloney) will publish the interviews to the Community Blog before the start of the voting period on Friday, 2026-05-29.
All elected seats are for two-release terms (approximately twelve months). For FESCo specifically, a new two-term consecutive limit was introduced in this election cycle. For more information about FESCo, please visit the FESCo docs.
The full schedule of the elections is available on the Elections schedule. For more information about the elections, process see the Elections docs.
Starting this month, Log Detective will provide an analysis of failed Packit-triggered scratch Koji builds on dist-git pull-requests.
Packit will keep on doing what it’s good at, integrating upstream projects with downstream distributions. Only now, it will have Log Detective to explain package build failures.
In Copr, the user can already request a Log Detective analysis by clicking on the “Ask AI” button.
In Packit, a build failure triggers a request for analysis automatically and presents the result in the dashboard, when it is ready.
The analysis does not require any additional setup. It is not necessary to choose which logs to send or to tune a prompt. Our service handles everything for you.
Log parsing and analysis derivation
Starting with version 4.0, the Log Detective works as an agent written in the BeeAI Framework.
The agent receives all logs and other build artifacts, as a part of the analysis request. Log Detective then uses a variety of tools, mostly based around the Drain template mining algorithm, to extract potentially useful snippets from the files. These snippets represent only a small fraction of the original log file size.
By extracting and using snippets, instead of entire original logs, we save tokens and limit the time needed for the analysis to finish. We also limit the amount of useless information in the model context.
This approach allows us to use even relatively small models and still get good results.
Communication architecture
Packit service handles failed Koji builds in the same way as before. However, Packit now also requests an analysis of a failed build by sending a request to the Log Detective interface server. The interface server, designed as a lightweight containerized service, handles all communication between the Log Detective and Packit services.
Packit sends a request for analysis to the Log Detective server. When the results are ready, the interface server posts them on the Fedora Messaging bus where Packit collects them.
Result presentation
An analysis from Log Detective consists of a statement of what, if anything, went wrong during the package build, and optionally, a suggestion of a solution. In the current configuration, Log Detective does not use sources other than build logs for the analysis.
Packit dashboard links Log Detective results to the PR that has triggered them.
Purpose and limitations
Since Log Detective uses a general purpose model, and lacks access to other information sources, it is obviously limited. Therefore it is not, and cannot be a substitute for years of experience in package maintenance in the Fedora ecosystem. If you have been building packages for a while, it probably has little to offer you.
It is intended to help those who don’t have such experience, and hopefully make their job a little easier.
Future development
Log Detective is under active development and we are looking into ways to improve it. We are continually revising the Log Detective system prompt to improve response quality, while periodically comparing the overall performance against a selection of annotated build logs, which we are collecting on our website.
We also plan to reuse a select part of this dataset to create an additional information source for Log Detective, to further improve the quality of the analysis we provide.
In the future, we also plan to provide an analysis for Copr builds handled by Packit.
We are also considering ways of improving the presentation of an analysis, such as expanding the Packit dashboard results to include not only the final analysis, but also extracted log snippets that were used to derive it.
At Red Hat Summit 2026, we’re announcing Fedora Hummingbird — a new container-based rolling Fedora Linux distribution. This distribution provides access to the latest software as soon as it’s available upstream, which ensures that it’s up to date and secure.
Fedora Hummingbird primarily utilizes an image-based workflow, similar to containers, but also runs in virtual machines and even on bare metal. If you’ve been following Project Hummingbird‘s work on container images, or Project Bluefin’s work on the operating system, you already know the model. Fedora Hummingbird applies this model all the way down to the host OS.
The foundation for Fedora Hummingbird already ships today from the Hummingbird containers repository. You can pull and boot it right now.
What is Project Hummingbird?
The central goal of Project Hummingbird is to get as close to zero CVE reports as possible in every container image it ships, and to stay there continuously. The team made every architectural decision, including distroless images, minimal package footprints, hermetic builds, and the degree of pipeline automation, in service of that goal. “Distroless” means no package manager, no shell, just the application and what it strictly needs to run.
Why does this matter? When you pull a third-party container image today, you inherit its vulnerabilities and you’re on the hook for managing them. Pull a Hummingbird image and the team’s pipeline has already done the CVE triage, the patching, and the rebuild – you get to skip CVE hell. (If you’re curious, current CVE status across all images and variants is published live at the Hummingbird catalog).
Over the past eight months, the team has built a catalog of 49 unique minimal, hardened, distroless container images (that’s 157 variants including FIPS and multi-arch) covering Python, Go, Node.js, Rust, Ruby, OpenJDK, .NET, PostgreSQL, nginx, and dozens more. Distroless means no package manager, no shell, just the application and what it strictly needs to run.
How it’s built
The infrastructure behind this is a Konflux-based pipeline. It uses fully isolated, reproducible builds from pinned package lists, efficient incremental updates via chunkah (a tool the Hummingbird team built to ensure the system re-downloads only changed parts of an image), and continuous vulnerability scanning via Syft and Grype. When a vulnerability is patched upstream, the pipeline finds it, rebuilds, tests, and ships.
95%+ of the packages in every Hummingbird image come straight from Fedora Rawhide, unmodified. The build system pulls the remaining packages directly from upstream when Rawhide doesn’t yet carry them or isn’t new enough, and the team contributes changes back into Fedora. If that sounds like Fedora CoreOS, that’s because it’s a related idea, but serving a different use case. CoreOS is a minimal host for orchestrated workloads. Hummingbird serves developers who need to deploy multiple versions of runtimes (Python 3.11–3.14, Go 1.25–1.26, Node.js 20–25) in parallel and manage each version’s lifecycle independently.
The Hummingbird factory independently builds packages so they carry their own identity. This means each package can have a separate life cycle, patching policy, and CVE feed (specifically, a vulnerability feed that Red Hat’s Product Security team maintains). Every package ships with machine-readable vulnerability data that tells you not just which CVEs exist, but which ones actually affect your workload.
The OS as a container image
The challenges that Project Hummingbird seeks to address in userspace exist at the OS level as well, so we want to apply the same approach to addressing those challenges. This is where Fedora Hummingbird comes in. This image is already live at https://quay.io/repository/hummingbird-community/bootc-os. The team delivers this full Linux OS as an OCI image, and they build it using the same Konflux pipeline and hermetic RPM-locking approach as the rest of the Hummingbird catalog. Multi-arch: x86_64 and aarch64.
Under the hood, Fedora Hummingbird will use the ARK kernel (Always Ready Kernel) from the CKI project (already running in Fedora today) which tracks Linus’ mainline directly. The benefit of leveraging the CKI project is the curated kernel configuration and elaborate engineering framework that includes extensive testing around a fast-moving kernel stream.
The Fedora bootable containers initiative laid out the groundwork for all of this. The idea is that the OS is an OCI image, built and distributed like any other container, and updated atomically with rollback built in. No partial update states. No configuration drift. The root filesystem is read-only. Any writeable state lives in /var and /etc, cleanly separated from the OS content.
The Hummingbird bootc OS image boots today. What’s still in progress is the integration work. The image is currently a mix of Hummingbird-built RPMs and Fedora packages, and we’re working out how to bring the two closer together. That’s exactly the kind of work we’d love to collaborate on.
Hummingbird in the Fedora community
Many members of the Hummingbird team are already Fedora contributors and package maintainers – maintainers of Podman, and other container tools that Fedora and the broader Linux ecosystem depend on, as well as maintainers of Fedora CoreOS. Members of the Fedora community contributed the bootable containers work that underpins Fedora Hummingbird. Now those members are continuing the work as part of Hummingbird. Moving forward, we’d like to make Hummingbird a part of the Fedora Project so that it can benefit and grow within that same community.
The Hummingbird pipeline already builds and publishes a set of container images based entirely on Fedora Rawhide at quay.io/organization/hummingbird-rawhide. The team has already started bringing improvements back to Fedora. These include container-specific optimizations, bugs found in .spec files, and more. The vulnerability feed that ships with Hummingbird packages is something we think could benefit the broader Fedora ecosystem too.
Getting started
Here are some quick-start instructions for getting a virtual machine up and running:
When you’re ready to try it, there’s no registration form, no subscription-manager, no entitlements required. The code is already there and the pipeline is already running — we’d love more eyes on it. Here’s how to jump in:
Try the image: You can find instructions on using the image on Quay
File issues and feedback: anything broken, missing, or surprising is worth reporting at this stage
Contribute: the project currently lives at gitlab.com/redhat/hummingbird/containers — establishing a home in Fedora’s own infrastructure is part of the work ahead
Join the conversation: visit the SIG page for info on our getting-started sessions.
Fedora has always been where the community proves out new Linux ideas before they matter everywhere else. Fedora Hummingbird is an experiment for image-based, continuously-maintained operating systems, and we think it’s ready for the community to kick the tires.
This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infrastructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.
Week: 4 – 8 May 2026
Fedora Infrastructure
This team is taking care of day to day business regarding Fedora Infrastructure. It’s responsible for services running in Fedora infrastructure. Ticket tracker
Copyfail: updated and rebooted key Fedora hosts, applied kernel team recommended mitigation on key EL 9 hosts
CentOS Infra including CentOS CI
This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure. It’s responsible for services running in CentOS Infrastructure and CentOS Stream. CentOS ticket tracker CentOS Stream ticket tracker
This team is taking care of day to day business regarding Fedora releases. It’s responsible for releases, retirement process of packages and package builds. Ticket tracker
Post-release cleanup.
RISC-V
This is the summary of the work done regarding the RISC-V architecture in Fedora.
OpenJDK CVE updates Wrote up initial analysis. Created an F44 branch with three small RISC-V patches on the secondary dist-git. Kicked off a boot JDK build.
Flock prep: Started writing up notes about the updates for our talk on RISC-V. If logistics work out, we may bring a board or two for a demo.
Explore shipping some upcoming RVA23 hardware (“SpacemiT K3”) for JasonM and DavidA for Koji builders. Figure out approximate costs for it.
Continued with LLVM’s ‘libomp’ test failures investigation; it’s a slow grind.
Caught up with Adam Williamson’s nice talk on lessons from root cause analysis.
AI
This is the summary of the work done regarding AI in Fedora.
This team is taking care of quality of Fedora. Maintaining CI, organizing test days and keeping an eye on overall quality of Fedora releases.
Fedora QE Pagure -> Forge migration is now fully complete. The new version of Blockerbugs (that uses Forge instead of Pagure for blocker discussion tickets) is now deployed to production.
This is a report created by the CLE Team, which is a team containing community members working in various Fedora groups, for example, Infrastructure, Release Engineering, Quality, etc. This team is also moving forward with some initiatives inside the Fedora project.
Week: 27 April – 01 May 2026
Fedora Infrastructure
This team is taking care of day to day business regarding Fedora Infrastructure. It’s responsible for services running in Fedora infrastructure. Ticket tracker
Put risc-v Koji behind anubis and tightened its robots.txt to mitigate a scraper flood
Somehow managed to keep the lights on with Kevin on PTO, teamwork win!
Status.fpo webpage does not pickup status changes merged into status github repo
Signing problem with the latest rawhide kernels
vmhost-x86-copr04 rebooting
CentOS Infra including CentOS CI
This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure. It’s responsible for services running in CentOS Infratrusture and CentOS Stream. CentOS ticket tracker CentOS Stream ticket tracker
ELNBuildSync is unable to connect to Fedora Messaging
Add GenericCloud images tests on testing.stream.centos.org
Please add ogajduse to ocp-cico-foreman
Fix openshift underlying issue (investigate) and upgrade
Replace sigs.centos.org infra with el10 host
Modernize centos mirror network CDN
Create an “ansible-init” tool or container
Release Engineering
This team is taking care of day to day business regarding Fedora releases. It’s responsible for releases, retirement process of packages and package builds. Ticket tracker
Release of Fedora 44 and torrents.
Automation works for Mass Branching Bits.
Unretirement workflow is now being processed from the fedpkg command; I found one bit to solve, which is being worked on.
Samyak is trying to solve the dependency checker, which didn’t account for alternative providers and rich dependencies.
RISC-V
This is the summary of the work done regarding the RISC-V architecture in Fedora.
F44 rebuild update (community work): 60% of rebuild is done so far. (This is expected as we’re with reduced Koji builders for a little while.)
LLVM related debugging (this is slow-grind work)
Started a local rebase of my Fedora LLVM patches in my fork. I still have to test it on P550 and submit for review. The builds are time-consuming; it’ll be a background task over the week.
Resumed debugging ‘libomp’ test suite failures. Setup an environment on DP1000.
Explored what it takes to create a shadow Koji instance for RISC-V that tracks Rawhide. DavidA already tried several years ago and had to drop it due to deep-sync issues; there are some workarounds to deal with it today. (Half-baked ideas: we could write an updated koji-shadow but it’s time-intensive. Experiment with a local copy, we don’t want to mess with the active RISC-V Koji instance. (Also needs a capable “volunteer” with time to try this out.)
Investigated and ordered an eGPU (external GPU) docks; last time I looked the one we needed was out of stock. Luckily one came back in stock. This dock helps us drive Tenstorrent’s AI accelerator card.
QE
This team is taking care of quality of Fedora. Maintaining CI, organizing test days and keeping an eye on overall quality of Fedora releases.
Executive summary: F44 signed off and released, LFNW, blockerbugs forgejo migration and test enablement work
awilliam attended LinuxFest Northwest (with brendan, carl and gordon), gave a well-attended talk on root-causing theory and practice – video, slides , did booth duty
PR to add openQA test of installing with a kickstart containing a non-existent package is blocked because anaconda handling of this is currently broken, anaconda team working on a fix
Blockerbugs port to Forgejo is merged, deployed to staging and undergoing testing
We are happy to announce the general availability of Fedora Asahi Remix 44. This release brings Fedora Linux 44 to Apple Silicon Macs.
Fedora Asahi Remix is developed in close collaboration with the Fedora Asahi SIG and the Asahi Linux project. This release incorporates all of the exciting improvements brought by Fedora Linux 44. Fedora Asahi Remix 44 also retires our vendored Mesa and virglrenderer packages. Users who have not already manually done so will be automatically transitioned to the upstream Mesa and virglrenderer packages provided by the upstream Fedora repositories.
Fedora Asahi Remix offers KDE Plasma 6.6 as our flagship desktop experience, with all of the new and exciting features brought by Fedora KDE Plasma Desktop 44. Plasma Setup replaces the previous Calamares-based setup wizard, providing a Plasma-native experience for user account creation and system setup. Additionally, Plasma Login Manager is now the default greeter and session manager, replacing SDDM. This applies to new installs only; users upgrading from previous versions of Fedora Asahi Remix will not have their configuration changed.
A GNOME variant is also available, featuring GNOME 50, with both desktop variants matching what Fedora Linux offers. Fedora Asahi Remix also provides a Fedora Server variant for server workloads and other types of headless deployments. Finally, we offer a Minimal image for users that wish to build their own experience from the ground up.
You can install Fedora Asahi Remix today by following our installation guide. Existing systems running Fedora Asahi Remix 42 or 43 can be updated following the usual Fedora upgrade process. Upgrades via GNOME’s Software application are unfortunately not supported; either KDE’s Plasma Discover or DNF’s System Upgrade command must be used.
Fedora has released Fedora KDE Plasma Desktop Edition 44 to the public.
The Fedora KDE Plasma Desktop Edition is suitable for many needs. It combines the reliable and trusted Fedora Linux base with the KDE Plasma Desktop environment. It provides a selection of KDE applications that are simple by default, but powerful when needed.
KDE Plasma 6.6
The KDE community makes your life easier with the latest release of KDE Plasma. It builds upon the foundations of Plasma 6 to provide a seamless, friendly, and familiar experience.
Fedora KDE 44 ships with Plasma 6.6.4 featuring:
Custom global theme creation by saving the current theme setup
More options for using color accent in windows with tint intensity for window frames
Support for connecting to Wi-Fi networks by scanning QR codes
Per-application volume adjustment from the task manager
New grayscale filter for colorblindness correction
New screen magnifier feature that tracks the mouse pointer
New “Slow keys” and “reduced motion” settings
Spectacle can do OCR scanning of images to capture text
Per-window filter from screencast through the menu in the title bar
Beyond just the updates included in KDE Plasma 6.6, there are some major new features with Fedora KDE on Fedora Linux 44.
Fresh installations now use the brand-new Plasma Setup and Plasma Login Manager. These provide a more cohesive and integrated experience from the moment the computer is powered on the first time. The installation process has been simplified. It now enables you to easily set up a computer with Fedora KDE Plasma Desktop for a friend or a loved one.
The on-screen keyboard uses the new Plasma Keyboard, providing a fresh and future-forward implementation for keyboard input.
Fedora Linux 44 general updates
Some broader changes in Fedora Linux also directly impact Fedora KDE Plasma Desktop Edition, notably:
PackageKit now uses version 5 of the DNF package manager as the backend.
Support for select Qualcomm-based laptops.
The /etc/pki/tls/cert.pem file no longer exists by default. This may impact some programs that expect this file to provide system CA certificates instead of leveraging behaviors built into cryptographic security libraries to offer this information.
Fedora Ready is ready for Fedora KDE
The Fedora KDE Plasma Desktop 44 edition is fully supported within the Fedora Ready program. Fedora KDE is actively engaging with hardware vendors to support Fedora KDE Plasma Desktop on their devices.
We are pleased to announce that Star Labs offers preinstalled Fedora KDE Plasma Desktop as an option for their portfolio of devices. As makers of computers with an open source ethos embedded into the core of their products with even open source firmware powered by Coreboot, they share many of the same principles the Fedora community values. This is a very exciting moment for Fedora KDE and we look forward to deepening our collaboration with Fedora Ready participants and extending to other vendors. If you are a vendor potentially interested in Fedora Ready, please reach out!
I’m happy to announce that we have sealed bootable container images ready for testing for the Fedora Atomic Desktops!
What are sealed bootable container images?
Sealed bootable container images include all the components needed to create a fully verified boot chain, from the firmware to the operating system composefs image. This relies on Secure Boot and thus only supports system booting with UEFI on x86_64 & aarch64.
The components are:
systemd-boot as bootloader
a Unified Kernel Image (UKI) which includes the Linux kernel, an initrd and the kernel command line
a composefs repository with fs-verity enabled. This is managed by bootc.
Both systemd-boot and the UKI are signed for Secure Boot. The images are test images so the components are not signed with the official keys from Fedora.
The main direct benefit that we will get from this support is that we will be able to enable passwordless disk unlocking using the TPM in a way that will be reasonably secure by default.
We welcome testing and feedback! Please see the list of known issues and report new issue at github.com/travier/fedora-atomic-desktops-sealed. We’ll redirect them as needed to the right upstream projects.
Beware, those are testing images. The root account does not have a password set and sshd is enabled, by default, to make debugging easier. The UKI and systemd-boot are signed for Secure Boot but, since those are test images, they are not signed with the official keys from Fedora. Don’t use those images in production.
Where can I get more details about how this works?
If you want to know more about how sealed images work (i.e. how we make bootable containers, UKI and composefs work together to create a verified boot chain), see the following presentations and documentation:
Fedora Linux 44 has been released! So, let’s see what is included in this new release for the Fedora Atomic Desktop variants (Silverblue, Kinoite, Sway Atomic, Budgie Atomic and COSMIC Atomic).
Changes for all Atomic Desktops
Issue tracker moved to the new Fedora forge
We have moved the cross-variants issue tracker to the new Fedora forge. This is the best place to file issues that impacts all variants or to coordinate work between all of them. If you have issues specific to a given desktop environment then we usually prefer to track them in each respective SIG trackers. These are available on the README for the atomic-desktops organization.
Unified documentation, hosted on the new forge
The unified documentation for all Atomic Desktops is finally live! Unfortunately the translations have not been migrated so we will need help to re-translate everything again, once the translation setup is ready with the new forge. It should be mostly copy/paste from the previous docs and this time we will only have to translate the docs once and not for every (new) variant.
Some AppImages are still using an old AppImage runtime that relies on FUSE 2 libraries being available on the host. See the Discussion thread for examples on how to check the runtime of an AppImage.
If some of your AppImages do not work on Fedora Atomic Desktops 44, we recommend:
Looking for a Flatpak for the application and giving it another try. Consider helping upstream package their application as a Flatpak.
Reporting the issue upstream so that they are aware that they should use a newer runtime. Consider helping upstream with this as well.
EncFS or CryFS backends for Plasma Vaults are removed
KDE upstream no longer recommends using the EncFS nor CryFS backends for Plasma Vaults, notably because they rely on the FUSE 2 libraries. If you are using one of those backends, you should migrate your data to a new vault using the only maintained backend (gocryptfs). Ideally this should occur before the update to Fedora Linux 44. If you have already updated to Fedora Linux 44 and need access to your data, you can layer the needed packages (cryfs or fuse-encfs) using rpm-ostree install <package>, then migrate your data and finally reset the layers with rpm-ostree reset.
Dropping compatibility for pkla Polkit rules
Support for the legacy pkla Polkit rules format has been removed. It is unlikely that you were relying on support for those rules as most of the ecosystem has moved on to the new JavaScript based format.
Unified out of the box experience with KDE Plasma Setup (OEM installation)
Thanks to the new Plasma Setup, it is now possible to install the system with Anaconda with minimal configuration and then complete the installation on the first boot by creating a new user and selecting the timezone. This is great when you want to install Fedora Kinoite on a computer and don’t want to setup a user in advance.
As always, I heavily recommend checking them out, especially if you feel like some things are missing from the Fedora Atomic Desktops and you depend on them (NVIDIA drivers, extra media codec, out of tree kernel drivers, etc.).
What’s Next
Helping us with a few nasty bugs
If you have an interest in contributing to Fedora Atomic Desktops, here are some bugs that we will have to fix in the short term. We would greatly appreciate help with:
Fixing root mount options (atomic-desktops#72): This is a long standing and mostly invisible bug that impacts performance.
Moving away from nss-altfiles (atomic-desktops#108): This is another long standing source of issues that new users regularly face.
A lot of work is happening to make the transition to Bootable Containers as smooth as possible for our existing users. You can look at the road map for this transition at atomic-desktops#26.
Fedora Silverblue is an operating system for your desktop built on Fedora Linux. It’s excellent for daily use, development, and container-based workflows. It offers numerous advantages such as being able to roll back in case of any problems. If you want to rebase to Fedora Linux 44 on your Fedora Silverblue system, this article tells you how. It not only shows you what to do, but also how to revert things if something unforeseen happens.
Update your existing system
Prior to actually doing the rebase to Fedora Linux 44, you should apply any pending updates. Enter the following in the terminal:
$ rpm-ostree update
or install updates through GNOME Software and reboot.
Note
rpm-ostree is the underlying atomic technology that all the Fedora Atomic Desktops use. The techniques described here for Silverblue will apply to all of them with proper modifications for the appropriate desktop.
Rebasing using GNOME Software
GNOME Software shows you that there is new version of Fedora Linux available on the Updates screen.
First thing to do is download the new image, so select the Download button. This will take some time. When it is done you will see that the update is ready to install.
Select the Restart & Upgrade button. This step will take only a few moments and the computer will restart when the update has completed. After the restart you will end up in a new and shiny release of Fedora Linux 44. Easy, isn’t it?
Rebasing using terminal
If you prefer to do everything in a terminal, then this part of the guide is for you.
Rebasing to Fedora Linux 44 using the terminal is easy. First, check if the 44 branch is available:
$ ostree remote refs fedora
You should see the following in the output:
fedora:fedora/44/x86_64/silverblue
If you want to pin the current deployment (meaning that this deployment will stay as an option in GRUB until you remove it), you can do this by running this command:
# 0 is entry position in rpm-ostree status $ sudo ostree admin pin 0
To remove the pinned deployment use the following command:
# 2 is entry position in rpm-ostree status $ sudo ostree admin pin --unpin 2
Next, rebase your system to the Fedora Linux 44 branch.
$ rpm-ostree rebase fedora:fedora/44/x86_64/silverblue
Finally, the last thing to do is restart your computer and boot to Fedora Linux 44.
How to roll back
If anything bad happens (for instance, if you can’t boot to Fedora Linux 44 at all) it’s easy to go back. At boot time, pick the entry in the GRUB menu for the version prior to Fedora Linux 44 and your system will start in that previous version rather than Fedora Linux 44. If you don’t see the GRUB menu, try to press ESC during boot. To make the change to the previous version permanent, use the following command:
$ rpm-ostree rollback
That’s it. Now you know how to rebase Fedora Silverblue to Fedora Linux 44 and roll back. So why not do it today?
FAQ
Because there are similar questions in comments for each blog about rebasing to newer version of Silverblue I will try to answer them in this section.
Question: Can I skip versions during a rebase of Fedora Linux? For example from Fedora Silverblue 41 to Fedora Silverblue 44?
Answer: Although it could sometimes be possible to skip versions during rebase, it is not recommended. You should always update to one version prior (41->42->43->44 for example) to avoid unnecessary errors.
Question: I have rpm-fusion layered and I get errors during rebase. How should I do the rebase?
Answer: If you have rpm-fusion layered on your Silverblue installation, you should do the following before rebase:
After doing this you can follow the guide in this blog post.
Question: Could this guide be used for other ostree editions (Fedora Atomic Desktops) as well like Kinoite, Sericea (Sway Atomic), Onyx (Budgie Atomic),…?
Yes, you can follow the Rebasing using the terminal part of this guide for every Fedora Atomic Desktop. Just use the corresponding branch. For example, for Kinoite use fedora:fedora/44/x86_64/kinoite
This article highlights a few noteworthy changes in the latest release of Fedora Workstation that we think you will love. Upgrade today from the official website, or upgrade your existing install using GNOME Software or through the terminal with dnf system-upgrade.
GNOME 50
Fedora Linux 44 Workstation ships with the latest GNOME release, GNOME 50. This comes with a long list of refinements to your desktop, including everything from accessibility, to color management and remote desktop.
As part of the Digital Wellbeing initiative, new native Parental Controls let you set screen time limits and bedtimes directly from Settings.
Many of the applications that are installed by default on the Fedora Workstation have also seen improvements, from the Document Viewer to the File Manager and the Calendar.
To learn more about these and other changes, you can read the GNOME 50 release notes.
) (There’s quite a bit more, but I think that sort of covers it. 
You went above and beyond - Fedora Project would not be the same without you!
You attended the Fedora Mentor Summit 2026
Poland. The Session is one of the oldest and biggest FLOSS-focused conferences in Poland. The event was organized by 
”
You went above and beyond - Fedora Project would not be the same without you!
You visited Fedora and CentOS at Red Hat Summit 2026
So, let’s see what is included in this new release for the Fedora Atomic Desktop variants (Silverblue, Kinoite, Sway Atomic, Budgie Atomic and COSMIC Atomic).
