/rss20.xml">
fedora

Fedora People
Blog List
RSS 1.0 RSS 2.0 Atom 1.0 FOAF blogroll

Community Update – Week 27

Posted by Fedora Community Blog on 2026-07-03 11:00:00 UTC

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: 29 June – 3 July 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

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

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 investigation into building a Fedora container base image using Konflux.
  • Continued work on remaining Pagure -> Forgejo migrations.
  • F45 release cycle is set to begin soon, starting with Mass Rebuild in the middle of July. This will require some prep work next week.

RISC-V

This is the summary of the work done regarding the RISC-V architecture in Fedora.

  • Discussion with Scaleway (a cloud vendor in France) for potential Fedora Koji builders in their Paris datacenter.  To be coordinated via RISE.
  • Hardware
    • Coordinated shipping another “K3” hardware to DavidA (one of the Fedora RISC-V maintainers). This will be used as another RISC-V Koji builder.  Sponsored by CLE.
    • Milk-V Titan hardware is now available to buy.  A handful of machines are being shipped to a couple of  RISC-V engineers, including for Fedora use.
  • Community work
    • Fedora Omni kernels for Muse Pi Pro hardware discussion with Trevor from Baylibre and Jason (Fedora RISC-V kernel)
    • Marcin (hrw) Juszkiewicz continues to chip away at the Fedora RISC-V tracker
    • Fedora Omni kernel work continues, with support for Muse Pi Pro, K3, and more: Jason Montleon and Jennifer Berringer
  • Other:
    • Discussions on ‘fedora-devel’: “How can we improve the Changes Process?” thread
    • A lot of internal discussion about 2FA for packagers
    • Several internal  and upstreams meetings

AI

This is the summary of the work done regarding AI in Fedora.

  • Aurelien Bompard improved the This Week in Fedora script to include the CLE status reports

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.

Forgejo

This team is working on introduction of https://forge.fedoraproject.org to Fedora
and migration of repositories from pagure.io.

  • Forge 15.0.3 in staging
  • New runner for koji organization
  • Continued work on Private Issues: public/private comments
  • Zabbix template developed to monitor health of runnerhost VM, moving onto the  forge instance next.

EPEL

This team is working on keeping Epel running and helping package things.

  • Updated caddy in f44, f43, epel10.3, and epel10.2 resolving 22 CVEs
  • EPEL 11 planning discussions

UX

This team is working on improving User experience. Providing artwork, user experience,
usability, and general design services to the Fedora project

  • Open Call for Fedora Event Video Footage! [discussions post]
  • Feedback period for F45 wallpaper has just ended. Here is the current iteration.

If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.

The post Community Update – Week 27 appeared first on Fedora Community Blog.

How Flock to Fedora Gets Organized

Posted by Justin Staging Fedorable on 2026-07-02 08:00:00 UTC
How Flock to Fedora Gets Organized

Flock to Fedora is the flagship contributor community event for the Fedora Project. A lot of work goes into Flock, with planning efforts usually kicking off ten months before the conference target dates. This is often the invisible work which the community rarely gets a window into seeing.

This blog post pulls back the curtain on what it actually looks like to organize Flock. It is the second post in a three-part series on Flock to Fedora 2026. The first post covers the highlights of what happened at the event.

The FCA Role and Flock

Flock to Fedora is a key part of the Fedora Community Architect (FCA) role at Red Hat. It is the flagship event of the Fedora Project community, and all three FCAs before me played pivotal roles in the organization of Flock to Fedora. However, Flock is the only event of its kind that I organize in the calendar year. While I support other events in the Fedora community, I do not take the role of a core organizer in any other event like I do with Flock.

There is a structural tension in the FCA role when it comes to Flock. There are several months of the year where the Flock event planning workload is light, and we are working through small steps at a time. But in the two to three months before Flock, the workload ramps up significantly. The team is working together more often and there are more tasks to coordinate. Meanwhile, the rest of the FCA’s responsibilities — supporting the community, budgeting, coordinating with Red Hat — do not scale down to make room.

This is not a new challenge; it is endemic to the role. All four years I have been involved as a core Flock organizer, this dynamic has been present. Perhaps there is a way to streamline and schedule Flock in a more programmatic way, so certain steps can happen earlier and others can get involved and help out. It is worth noting for anyone who inherits or reshapes this role in the future.

The Flock Organizing Team

Flock to Fedora would be nothing if not for the people who put in the time, effort, love, and care to make it the community event that it is. It is because of the amazing colleagues and teammates in the Flock core planning team that we pull off the high-quality, engaging event we do. I am incredibly grateful to the various folks who contribute various levels of time into the Flock event planning process. So, this section of my post is where I give some sincere thank-yous to Fedora Friends who take up an exceptional share of the planning work. All names are in alphabetical order:

  • Allison d’Amboise: Operations support, sponsorship & legal support

  • Ananya Nalavathu: Foundations Wall, social media support, #CommitHistory interview campaign

  • Aoife Moloney: Event Co-Lead

  • Dorka Volavkova: Event Co-Lead

  • Emma Kidney: Design, print, & brand/identity support

  • Greg Sutcliffe: Matrix virtual experience support

  • Jason Brooks: Operations support

  • Jef Spaleta: Strategic support

  • Jennifer McGinnis: Operations support

  • Jennifer Schimmoller: On-site event support, logistics, and event execution

  • Jess Chitas: Flock website UI/UX improvements

  • Jona Azizaj: Event Co-Lead

  • Joseph Gayoso: Social media support

  • Juliana Furlow: Sponsored Travel coordinator

  • Kevin Fenzi: Matrix virtual experience support

  • Lidija "Lydia" Balija: CfP lead, ops support

  • Madeline Peck: Design, print, & brand/identity support

  • Shaun McCance: Event Co-Lead

A photograph of four smiling Flock to Fedora organizers posing together at the Monday night social reception. They are standing in front of a warmly lit bar area and a large blue Fedora graphic banner. Left to right: Jennifer Schimmoller, Dorka Volavkova, Jona Azizaj, Aoife Moloney.
Figure 1. Four Flock to Fedora organizers standing together and smiling at the Monday night social reception. Y’all are amazing! Left to right: Jennifer Schimmoller, Dorka Volavkova, Jona Azizaj, Aoife Moloney.

There are even more people who have contributed something to Flock. But these are the people who went above and beyond to contribute to the success of the event. I could not do Flock without each and every one of them!

Workflow Experiment: Public Issue Tracking

I also tried out a new approach to public project management for Flock 2026. There is a new Fedora Forge repository under the Fedora Council organization, council/flock. I attempted to use this as a way to track ongoing work and have more public-facing project management to demonstrate what actually goes into executing Flock.

A screenshot of a dark-themed issue tracker for the "council/flock" Fedora Forge repository, displaying a list of seven open and 119 closed tasks. The visible open issues include post-event tasks such as processing reimbursements and publishing session recordings, each detailed with color-coded area and priority labels, the "2026 Post-Event" milestone, progress bars, assignee avatars, and comment counts.
Figure 2. A screenshot of a Fedora Forge issue tracker for the council/flock repository displaying various open and closed Flock 2026 event management tasks.

I rate the use of this experimental repository as a mixed success. Its biggest issue was that it was incorporated late into the planning cycle and I did not involve other Flock team members in the repository workflow. So, it was largely a tool that I used alone. I provided few and sparse updates until May on the various issues.

I did use AI-assisted workflows to help process meeting summaries and transcripts into issue updates. Our Flock 2026 organizer team was already using AI assistance for note-taking and generating transcripts from our regular video meetings. After Flock ended, I used a structured interview format with an AI agent to review all open issues in the Fedora Forge API, answer follow-up questions about their status, and create a record of what was accomplished and what remained.

While this tool was not directly useful to planning Flock 2026, it could be a useful starting point for other tools to analyze, plan, and suggest timelines for various Flock planning and execution work. The final goal in using the repository after Flock 2026 was to get unwritten institutional knowledge into a public issue tracker so it could be referenced in the future when we actually need to look back and remember what we did before and what lessons we learned.

Paperwork: Sponsor Contracts

It is the most boring thing ever, perhaps, but Red Hat Legal approved an updated Flock to Fedora sponsor contract. This is something that me and my colleague Shaun McCance have been working on for years, as part of the CentOS Connect and Flock to Fedora event planning. The challenge with our old sponsor contract was that it had requirements which did not actually make sense for Flock. For example, a sponsor had to provide a proof of insurance with a significant deductible for their event sponsorship. This is actually somewhat standard for corporate events where companies rent big, expensive exhibit booths. But Flock does not have, and never had, sponsor booths. Our community is always too immersed in the hallway track, and we encourage sponsors to send their reps to participate in the hallway track to get more out of their sponsorship.

While the insurance requirement was one of the most notorious challenges, especially for smaller companies and organizations, there were other changes made as well. I will not list them all, but the greatest advantage of this was the ability to bring back some past sponsors due to less corporate verbiage in the contract, and more community-friendly language. We did not add anything new to the contract; we only removed lots of content and sections. All in all, this made our contracts shorter, leaner, more aligned with the actual event we produce, and importantly, easier for other company’s legal teams to review, process, and sign.

We got these updated contracts in January, which was part of why we were delayed somewhat in our sponsor outreach. However, now that we have the updated contract, we can start earlier on the sponsor outreach since we will only have to get an approval next year on a contract update which mostly changes dates, years, and not much else.

More in this series

Flock to Fedora 2026: What Happened

Posted by Justin Staging Fedorable on 2026-06-30 08:00:00 UTC
Flock to Fedora 2026: What Happened

In the blink of an eye, it was over almost as quickly as it began. But the three days at the annual Flock to Fedora conference from 14–16 June 2026 in Prague, Czechia were packed with the kind of engagement that keeps the Fedora community going. Flock to Fedora, or often simply referred to as Flock, is the flagship contributor community event for the Fedora community. Flock is a place where the "doers" of our community gather annually to share our work, discuss ongoing collaborations, and shape the future of our next year ahead. Ultimately, it is one of my favorite parts of the Fedora Project. Being one of the lead organizers is one of the greatest privileges of serving in the Fedora Community Architect role at Red Hat.

This blog post is my attempt to capture the highlights of Flock 2026 while they are fresh in mind. The Linux and open source media already began their coverage. So, I thought this was a good moment to share my perspective on the event. This was my ninth Flock that I have attended and the fourth Flock where I played a leading role as an organizer.

The Hallway Track

I often tell people that the 45 days before Flock are some of the most stressful days of my entire year. But all four times I have done this, once I actually arrive at Flock and the conference gets going, the stress melts away. I am still running around a lot, taking care of this or that, but the important things always come together. Our speakers deliver great content, people reconnect after a long time of not seeing someone, and the hallway track is constantly lively. This year was no exception. I was pleasantly pleased to see and hear the community vibe which is essential to Flock was once again re-created.

Both my lived experience from nine years of Flock and the post-event data since we began collecting it in 2024 tells us one thing, absolutely. One of the most-valued parts of the Flock to Fedora experience is what is commonly known as "hallway track." If this is a new term to you, it is not too hard to understand. It plays on the idea that while there are usually tracks of speaker programming and content at a conference, there is also an unspoken track on the schedule. This "hallway track" is the informal conversations that take place outside of the speaker halls. They happen organically and they are usually unscripted. In-person attendees of Flock have been telling us for years that the "hallway track" at Flock is a critical, spotlight part of what makes the event worth attending.

A group selfie of several individuals wearing blue Flock to Fedora conference lanyards gathered around a long dining table in a room with large glass windows. A handwritten sign reading "Development" sits on the table among plates and glasses as the group poses for the camera held by a man in the foreground.
Figure 1. A group selfie of people wearing blue Flock to Fedora conference lanyards seated at a dining table featuring a handwritten "Development" sign.

So, while it appears the Fedora community has vast opinions about Flock, what it is, and what it is supposed to be, we all seem to agree on one thing. Getting the face-time to speak with other Fedora contributors is invaluable and drives critical engagement that keeps people in our community. I genuinely think without Flock to bring our core contributor community together once a year, we might all be burnt-out, exhausted, and tired from the online engagement we have been doing for more than 23 years. The in-person time is where the Fedora Friends Foundation comes out on full display. The hallway track is where people can go from colleagues to friends. When we talk about building trust in a community, it is experiences like the Flock to Fedora hallway track that turn trust-building from a concept to a concrete, practical thing.

"Generational Switchover" and Packager Data Trends

One of the most poignant parts of Flock 2026 came in the "State of Fedora" keynote delivered by the Fedora Project Leader, Jef Spaleta. Several thoughts were put forward, but what clearly generated buzz was a graph produced by Michael Winters from the Fedora Data Working Group.

A line graph titled "Year-over-Year Package Committers by Month." The x-axis tracks the month from 1 to 12. The y-axis measures unique Fedora package committers from 320 to 460. The graph plots data and dashed trend lines for three distinct years: 2020 in blue with a trend slope of -1.90, remaining mostly above 420; 2023 in orange with a steeper trend slope of -6.02, steadily declining from roughly 410 to 335; and 2026 in green, which only includes data for months 1 through 4, starting at 350 and dropping to 325 with the steepest trend slope of -8.70.
Figure 2. A line graph titled "Year-over-Year Package Committers by Month" showing a downward trend in the number of unique Fedora package committers across the years 2020, 2023, and early 2026.

Michael single-handedly developed user-level access to the wealth of packaging data we have been working to analyze, and the result was a striking visualization of the number of unique package committers in Fedora over a six-year span. The graph shows what seems to be a significant decline of the number of unique packagers actually working in Fedora Linux over a six-year span. The data appears to indicate a sharp decline in the number of unique packagers in 2026 so far versus the unique packagers in 2020 and 2023. It is a graph that is certainly concerning.

Jef put forward theories of what he thought the data could be indicating. At one point, he mentioned the idea of generational switchover, and that one era is ending and a new one is beginning. In the session following his keynote, the Fedora Council Q&A, this topic of generational switchover came up even more. Obviously, people felt concerned or triggered in some sort of way by this data. While the Fedora Council originally planned for the panel to focus more on a "what/how" conversation, we ended up having more of a "why" conversation with attendees.

It was a comment made by Aleksandra Fedorova which really stuck with me. At one point, she and I had touched on a shared experience for an in-person F41 Release Party in Potsdam, Germany. The interesting part of this was the unique intersection of both the local organizer, René Kuhn, and newcomer, junior students from the university (i.e., where the event was held) and old-timer, experienced contributors like myself and Aleksandra. Aleksandra mentioned that her experience at this F41 Release Party reminded her that the young people and students of today were just like many of us with several years behind us were when we began in Free Software and Open Source. She said that it was not actually young people who were changing, but us, the people who had been here for years, who have changed. We are no longer the same young people we were. We are more experienced, more exhausted, perhaps more burnt-out, than we were in our own youth and entry to the Free Software movement. I encourage you to watch the full panel discussion once it is available, but this is a thought that is sticking with me after Flock ended.

Record-Breaking Sponsor Engagement

We had a record-breaking level of engagement on the sponsor side of Flock 2026. We raised more sponsorship funding from a larger number of unique sponsors than we have received in years. This milestone shows us a couple of things:

  • We have a diverse group of engaged sponsors, mostly from downstream products and companies, which care about the sustainability and well-being of Fedora.

  • We are growing the amount of sponsorship for Flock to Fedora, which can enable us to think on a bigger, grander scale for future editions.

  • Our processes are getting better at selling Flock sponsor packages, and processing contracts, purchase orders, and invoices.

The sponsorship side of Flock really became more critical after the COVID-19 pandemic, when we returned to Flock to Fedora after a few years of Nest with Fedora virtual conferences. I remember as an attendee from 2015 to 2019 that while there were other sponsors, it was obviously Red Hat who was the most engaged, the most committed, and the one footing most of the actual costs. To be honest, this is still true today. However, the pool of engaged sponsors is diversifying. We have more commercial downstreams from Fedora Linux than we have ever had at any point in our history. To me, this represents healthy growth, even if it does raise more questions about how to sustain that growth and balance the increasing interest in Fedora Linux in a fair and equitable way.

Everyone tries to influence the direction of a project they care about. That is simply how communities work. What matters is whether the processes for exerting that influence are fair, equitable, and open to everyone. In Fedora, they are. Our sponsors do not buy influence in Fedora Linux. What is impressive about most of our Flock sponsors is that there are often coordinated groups of paid engineers and contributors from these companies who show up to do real, actual work in the Fedora community. They submit Fedora Changes, get them reviewed by FESCo, and integrated into Fedora Linux — the same process available to anyone. Our hardware vendor sponsors can also participate in initiatives like Fedora Ready, to provide greater assurance and information for Linux consumers to purchase hardware which has a guaranteed quality experience with Fedora Linux. Our sponsors are not complacent and they do not rely on financial sponsorship to get them special favors. If they want something done, they show up and do the work themselves, together with the input and participation of the rest of the community.

A special thank-you to the individual folks at our various sponsoring organizations who raise the Fedora Project flag in their teams, departments, and entire organization. Without you, these special, collaborative relationships we have would not be possible.

Fill Out the Flock 2026 Post-Event Survey!

If you are reading this blog post, attended Flock in-person or virtually, and it is before 8 July 2026, stop everything you are doing. Go and complete the Flock 2026 post-event survey right now. This is only because it is the most important part of the entire future Flock planning process. As one of the people with access to the data and also involved with the planning for future Flock editions, nothing else matters more than this. While I am always listening to what people have to say in the hallway or making my own observations at the conference, the survey gives us real data to understand what people think and feel about Flock to Fedora. I always read every single comment and response in the survey. It matters to the entire Flock organizing team that we build an event that reflects the desires and wishes of our community.

The survey is open to both in-person and virtual attendees. We know that the Fedora community is global and spread out all over the world. We also know that travel is not necessarily an equitable act; not everyone can afford to travel, or even is physically able to travel. Therefore, we invite everyone who considers themselves a part of the Fedora community and participating with Flock to share their opinions.

After all, if we only sent our survey to our in-person European conference attendees, it seems quite likely that we will keep hearing about how Europe is the best location for Flock. So, even our virtual attendees and people who could not travel in-person to Flock 2026 can share their feedback and voice to help us make a better and more inclusive Flock in the next editions.

Community Update – Week 26 2026

Posted by Fedora Community Blog on 2026-06-26 10:00:00 UTC

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: 22 – 26 June 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

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

RISC-V

This is the summary of the work done regarding the RISC-V architecture in Fedora.

  • F45 rebuild started — we’re trying to first focus on language toolchains — need to refer to Miro’s lightning talk from Flock on how they handled Python bootstrap
  • F44 is being kept up2date (there were some big updates, including GCC)
  • Kevin did the legwork to move away from old dist-git on fedora.riscv.rocks to forge.fp.o
  • Another K3 builder in Fedora Koji — another member added.  (This might sound like a tame update, but all compute power is helpful / important to keep the build momentum :-))
  • Discussed some details of riscv64 in primary Koji ticket
  • Slides for Flock RISC-V update

AI

This is the summary of the work done regarding AI in Fedora.

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.

  • Flock & DevConf attendance, lruzicka gave a talk on openQA test investigation, adamwill gave a lightning talk with cle about Fedora CI improvements, several of us were involved in a workshop/roundtable about the viability/desirability of moving all testing to dist-git PRs, lots of productive side conversations etc., many about AI – trip reports / blog posts coming
  • On-demand openQA test of dist-git PRs in progress
  • Looks like we maybe found some new maintainers for packager-dashboard
  • Lots of work to enable testing of the huge OpenSSL 4 update for Rawhide, investigate a significant bug that showed up, and eventually bypass the test failures for that bug as it’s proving not to be possible to resolve in a reasonable time (the update needed to get merged)
  • Continued tech debt / enhancement work on blockerbugs, testdays-web and issuebot

Forgejo

This team is working on introduction of https://forge.fedoraproject.org to Fedora
and migration of repositories from pagure.io.

  • PTOs & travel
  • On Zabbix staging, now have a working template to monitor the Forgejo runnerhost VM and the runners themselves
  • Continued work on Private Issues (private comments refactoring)

UX

This team is working on improving User experience. Providing artwork, user experience,
usability, and general design services to the Fedora project

  • Beta Wallpaper ticket closed

List of new releases of apps maintained by I&R Team

If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.

The post Community Update – Week 26 2026 appeared first on Fedora Community Blog.

Fedora Documentation translations again available

Posted by Fedora Community Blog on 2026-06-26 09:19:27 UTC

Updates to translations of Fedora Documentation are again available. As announced on March 3rd, the unavailability of translation updates was due to the migration of the translation repositories and necessary tools from Pagure to the Fedora Forge. It took longer than expected but we are pleased to report this undertaking came finally to the end.

The post Fedora Documentation translations again available appeared first on Fedora Community Blog.

Planned Outage - download-ib01, torrent, people outage

Posted by Fedora Infrastructure Status on 2026-06-25 20:00:00 UTC

We will be reinstalling the virthost that runs download-ib01, torrent.fedoraproject.org and fedorapeople.org. During the outage these sites will be down.

Fedora at XV P.I.W.O. Poznań Free Software Fest

Posted by Fedora Community Blog on 2026-06-25 10:18:38 UTC

On Saturday May 30th 2026, the XV edition of P.I.W.O. Poznań Free Software Fest was held in Poznań, 🇵🇱 Poland.

P.I.W.O. is an event with a long history. Between 2004 and 2018, it was organized by various student associations at the Poznań University of Technology. After 2018’s XIII edition (superstition much?), it entered a long hiatus that lasted until 2025, when members of the newly-formed Knyfyrtel Poznań Hackerspace decided to bring it back. The reactivated event proved a huge success, with the XIV edition bringing in 197 attendees. As such, ambitions for 2026 were rather big.

Teamwork makes the dream work

This year’s edition was the result of combined efforts of three Poznań-based organizations:

Photo of the organizing team, with 26 people visible in the picture. That's not the whole team!

Thanks to Webrains, for the first time in its history, the event was held at the Adam Mickiewicz University in Poznań – namely, the uni’s Faculty of Mathematics and Computer Science. Also a historical first, the XV edition was granted honorary patronage by the President of Poznań City Council.

Busy, busy day

The event spanned almost the entire Saturday, opening at 9:30 am and closing at 7:35 pm. The agenda was tightly packed, featuring 3 lecture tracks with 24 talks, 2 workshop tracks with 8 activities, plus a LAN Party track with 3 tournaments, as well as “free play” sessions. There was also a quiet corner where, thanks to the “Honte” group, attendees could relax and learn to play Go.

Photo of one of the lecture halls.
Photo of one of the workshop sessions.
Photo of one of the LAN Party tournaments, with the attendees playing Xonotic.

Throughout the years, one of P.I.W.O.’s hallmarks was the lunch break, with the attendees being provided free pizza. This year couldn’t be any different, with some 66m² (or 710 ft²) of pizza being delivered to the venue. (It disappeared frighteningly quick.)

Photo of the event hall, with the organizers setting up tables with pizza.
Focus photo of one of the organizers bringing in 5 boxes of pizza.

The Fedora Community was represented by:

  • Zbyszek Jędrzejewski-Szmek, who gave 2 (!) talks
  • Mat Holmes, who volunteered as a photographer
  • Kacper Skrzyński, who handled various urgent tasks
  • Artur Frenszek-Iwicki, who gave a talk and held a workshop session
Photo of (left to right) Artur, Mat and Zbyszek, standing behind a banner with the event's logo.

Historical moment: creation of SPOIWO

This year’s P.I.W.O. served as an opportunity to announce the creation of SPOIWO – Sojusz Przyjaciół Otwartego i Wolnego Oprogramowania (Alliance of Friends of Open and Free Software). This diverse coalition of social and technology organisations, cooperatives and open source businesses signed a declaration in support of digital sovereignty. The alliance was formed in response to the ever-deepening of public institutions’ dependency on closed platforms and their loss of control over data and communication.

Group photo taken after the signing ceremony of the SPOIWO declaration. The printed declaration is visible in the back, propped up above the heads of the people in front.

The signing ceremony also featured speeches by representatives of SUSE Poland, Polish Linux User Group, “Internet. Czas działać!” Foundation and PLZ Spółdzielnia.

Exceeding all expectations

The event wrapped with 452 attendee badges issued, which exceeded even the most daring of expectations. (The number also explains why the pizza disappeared so quick.) The bar for the next edition is set high, but so are the organizing team’s ambitions.

Photo of the people gathering at the freebie table, taken from the upper balcony.
Photo of the event hall, showing the mass of people present during the lunch break. Taken from the upper balcony.
Photo of people gathering at the freebie table. Two banners are visible in the background: at the back, the event's old promotional banner; at the front, the "All Creatures Welcome" banner.

If you’d like to learn more about the event, watch the live stream recordings, or subscribe to news so you won’t miss the announcement for the XVI edition – you can do all of that on the event’s website, at piwo.sh.

The post Fedora at XV P.I.W.O. Poznań Free Software Fest appeared first on Fedora Community Blog.

Partial Outage - 2 of 5 Openshift workers down

Posted by Fedora Infrastructure Status on 2026-06-25 09:30:00 UTC

Some hosts are being relocated and have been taken down for that purpose. OCP workers 04 and 05 are on the list.

While this should have been transparent to end users, it has caused unforseen consequences with the Apache LoadBalancer setup for Openshift Apps, when requests mistakenly get sent to …

Community Update – Week 25, 2026

Posted by Fedora Community Blog on 2026-06-23 10:12:46 UTC

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: 15 – 19 June 2026 (Flock Week!!)

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

  • Helped getting elnbuildsync moved into stg openshift (ongoing).
  • A couple more services had OS upgrades to Fedora 44.
  • Some more MirrorManager problems.
  • Scrappers found another ostree repo. on kojipkgs, limited dir. indexing to stop the attack and then searched for any other ostree repos. Hopefully the last time it happens.

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

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

  • Migration at 95%, the only thing left to migrate is majorly fedora-scm-requests, bug fixes, and continued releng operations.
  • Migration: archive-repo-manager from pagure
  • Fix: Missing permissions on releng/fedora-comps
  • Bug Fix: Mass tagging script for verification bits
  • F45 Change Sets reviews are in check and f45-python side tags are merged.
  • Regular releng operations.

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.

  • We’ve started searching for new owners/maintainers of Packager Dashboard and Oraculum

Forgejo

This team is working on introduction of https://forge.fedoraproject.org to Fedora
and migration of repositories from pagure.io.

  • Completed the Flock To Fedora 2026 presentation on Fedora → Forgejo migration efforts #588, packaged and deployed Forgejo 15.0.3 #620.
  • successfully ran the PR fix doctor across all migrated repositories #601 to address merge issues with Pagure imports.
  • Enhanced runner infrastructure with the addition of a Testing Farm runner option #619 and docker-slim type runner #568, and improved security by deploying oauth-proxy to secure the Forge metrics endpoint #571.

EPEL

This team is working on keeping Epel running and helping package things.

  • Updated caddy in rawhide, resolving 14 CVEs
  • Ongoing onboarding of Pedro

UX

This team is working on improving User experience. Providing artwork, user experience,
usability, and general design services to the Fedora project

  • With Flock this week, got to see how all the final designs turned out it in person!
  • Emma delivered her talk on ‘Why You Should Use Open Source Design in Open Source’ at Flock
  • Great progress on the F45 wallpaper in the final stretch!

If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.

The post Community Update – Week 25, 2026 appeared first on Fedora Community Blog.

Community Update – Week 24, 2026

Posted by Fedora Community Blog on 2026-06-23 10:07:47 UTC

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: 08 – 12 June 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

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

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

AI

This is the summary of the work done regarding AI in Fedora.

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: Python 3.15 and kmscon Changes landing caused some fallout, tool tech debt payoff / enhancement continues, most team members used Day of Learning for AI experimentation
  • Two major Changes landed: Python 3.15 and kmscon consoles, various fallout from that:
    • CoreOS and IoT both broken by the kmscon change
    • Got on-the-fly keyboard layout changes added (important for openQA)
    • Kickstart installs broken by Python 3.15 change (sent a fix)
    • Various openQA test updates required for kmscon fixes
  • openQA serial bug worked around, new packages now deployed to prod
  • Tech debt repayment and new feature work continue on testdays, issuebot and blockerbugs
  • Kparal continues to find bugs in Lenovo laptop support
  • Work on ELN kernel gating got blocked by an unfortunate pre-existing design problem
  • Worked with Cristian Le to get rpmdeplint pipeline updated so fixes from last ~year are in prod, it now runs in ~2 minutes instead of ~20
  • Team did some AI agent / skills experimentation during Day of Learning

Forgejo

This team is working on introduction of https://forge.fedoraproject.org to Fedora
and migration of repositories from pagure.io.

EPEL

This team is working on keeping Epel running and helping package things.

  • Executive summary: 
  • Completed archiving of EPEL 10.1
  • Package maintenance across multiple Fedora and EPEL packages
  • Quality work via bug reports and bodhi karma

UX

This team is working on improving User experience. Providing artwork, user experience,
usability, and general design services to the Fedora project

  • Final stretch prepping Flock materials – Fedora badge, livestream template, sponsor splash
  • Progress being made on the F45 Wallpaper
  • Emma gave a talk about the Fedora Design team at the Waterford office’s Fedora 44 Release Party last Wednesday 🎉

If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.

The post Community Update – Week 24, 2026 appeared first on Fedora Community Blog.

New badge: DevConf.cz 2026 Attendee !

Posted by Fedora Badges on 2026-06-18 11:59:07 UTC
DevConf.cz 2026 AttendeeYou attended the 2026 iteration of DevConf.cz, a yearly open source conference in Czechia!

Web-Based Remote Installation for Fedora Linux: Here’s What We’re Building

Posted by Fedora Magazine on 2026-06-17 08:00:00 UTC

If you’ve ever needed to install Fedora Linux on a headless server, a Raspberry Pi, or any machine without a monitor attached, you’ve probably reached for VNC or RDP. They work – but as the installer moves to a web-based interface, there’s a new opportunity to do something more native to that model. We’re building it, and we want your input before we go too far down a path that’s hard to reverse.

Why This Is Happening

The Anaconda installer’s Web UI first landed in Fedora Linux 42 Workstation and was extended to all Live spins in Fedora Linux 43. It’s a full graphical installer built on Cockpit tooling and using PatternFly widgets. The GUI is rendered in a fullscreen browser window – but until now, that browser had to be running on the same machine you’re installing onto.

Here’s the thing: VNC and RDP were built around the GTK interface. While RDP could technically work with the Web UI too (it operates at the display level), a remote browser is a much better fit – orders of magnitude less data and much lower UI latency. As the Web UI becomes the primary installer interface across Fedora Linux editions, it needs its own native remote access story.

On top of that, there are two more forces pushing in the same direction.

As browsers move toward Flatpak packaging – already the reality for atomic desktops and derivatives like Bazzite – remote installation opens an opportunity for shipping focused, smaller boot images that don’t need to bundle a local browser at all. A lightweight ISO aimed at headless and network install scenarios, where the assumption is that you’re connecting from another machine.

And once you have a browser-rendered installer, serving it to a remote browser is the natural next step anyway. A headless ARM SBC doesn’t need to run a GPU-accelerated browser locally just to show you a disk partitioning screen. Your laptop can do that for it.

What It Actually Is

The concept is pretty straightforward: Anaconda’s Web UI, already built on Cockpit, gets served over HTTPS. You point a browser at the machine you’re installing, authenticate with a PIN, and you’re controlling the installation remotely. No VNC client, no RDP client, no X forwarding. Just a browser.

If you’ve used Cockpit to manage a server, you already have a feel for the experience. The difference is that the machine you’re connecting to is mid-install, not running a full OS.

Use Cases

The ones we’ve talked through most:

Headless servers – You’re installing onto a server in a rack with no attached display. You expose the Web UI over the network and control everything from your workstation.

Lightweight ARM SBCs – Devices like Raspberry Pi have limited resources. With remote rendering, the Pi just runs the installer backend; all the UI rendering happens on whatever machine you’re connecting from.

Remote monitoring – Even if you’re not fully headless, being able to watch an installation from another machine is genuinely useful. Kick off a server install, go make coffee, check progress from your laptop.

The Design Decisions So Far

We’ve had some meaty discussions about how this should work, and a few things are now settled.

Authentication: You set a PIN through kickstart or boot options, and type it into the browser login page. Same pattern as VNC and RDP – the user provides the password, not the system.

TLS with self-signed certificates: The connection is encrypted, but the certificate is generated on the fly at boot. That means your browser will show the “this certificate isn’t trusted” warning. We’ve accepted this tradeoff – shipping a private key on installation media is a security risk, and the IP address isn’t known ahead of time, so standard PKI doesn’t really apply. For environments that need proper certificates (say, a university deploying at scale), Image Builder is likely the right path to embed custom certs. That’s a later problem.

Single connection only: Only one browser session can connect at a time. Two concurrent sessions could genuinely conflict – one session starting installation while another changes the storage configuration. So: one connection, full stop.

Reconnection behavior: If you disconnect and reconnect, what happens depends on where the installation was. Before the review screen – the point of no return – you start from step one. After the review screen (installation actually running), you land on the progress view. Simple two-state model, covers the critical cases.

Config isolation and port: All Cockpit configuration specific to remote installation lives in /etc/anaconda/cockpit/, not the default Cockpit paths – otherwise the config could leak into the installed system. We’re leaning toward port 443 by default so you can just point your browser at the machine’s IP without specifying a port, but the port will also be configurable.

How This Compares to VNC and RDP

VNC has been around in Anaconda for years; RDP support was added more recently. Both work by screen-sharing the GTK interface. Technically, RDP could work with the Web UI too – it operates at the display level, scraping pixels from the screen. But a remote browser is simply better: you send orders of magnitude less data and get much lower UI latency compared to streaming a full desktop.

Beyond performance, there are practical advantages. No client is required – any modern browser works. No VNC viewer to install, no RDP client to configure, no protocol quirks across platforms. And it’s the same Web UI we’re already actively developing, so features and fixes automatically benefit the remote experience. With VNC or RDP, you’re screen-sharing a separate GTK codebase – a separate maintenance burden.

VNC and RDP aren’t going away for now – they still work with the GTK legacy interface. But as the Web UI becomes the default across more Fedora Linux editions, browser-based remote access is where the investment goes.

Where We Are Right Now

This is a developer preview. Here’s what’s working:

  • Custom login page with PIN-based authentication
  • Separate socket-activated systemd unit for auth (clean separation from the main Cockpit process)
  • Session cookies that survive tab closes, require re-login on browser close
  • Cockpit config in an isolated, anaconda-owned path

Here’s what’s still open:

  • Single-connection enforcement (this will likely require close collaboration with the Cockpit team)
  • Backend detection of whether installation is already running (this is needed for proper reconnection behavior)

If you want to see the PoC in action, there’s a draft PR at rhinstaller/anaconda-webui#1274 with the authentication setup – custom login page, pin-based auth script, socket-activated systemd units, and the Cockpit config override. To try it yourself, clone the PR branch, build an updates image, and boot it with virt-install:

git clone -b poc-remote https://github.com/bruno-fs/anaconda-webui.git
cd anaconda-webui
make create-updates.img

virt-install \
  --name anaconda-remote-test \
  --ram 4096 \
  --vcpus 2 \
  --disk size=20 \
  --location /path/to/Fedora-Everything-netinst-x86_64-Rawhide.iso \
  --extra-arg "inst.updates=http://your-host:port/updates.img" \
  --extra-arg "inst.webui.remote"

This is a proof of concept, not production-ready code. The PIN is hardcoded to 1234, there’s no TLS, and single-connection enforcement isn’t in place yet. Don’t use this for real installations – it’s meant to show the direction and let you poke at the approach. Once the installer boots, point a browser at the VM’s IP and enter 1234 on the login page. It’s rough, but it runs.

What We Want to Hear From You

We’re sharing this now because some of these decisions are hard to unwind once the feature ships, and community input is more useful now than after the fact. A few things we’re genuinely thinking about:

Remote installation is opt-in – you enable it through boot options or kickstart. But here’s a question we’re genuinely considering: should we ship a lightweight boot ISO without a local browser, with remote installation enabled by default? A minimal image aimed at headless and network install scenarios, where the assumption is that you’re connecting from another machine. Would that be useful to you? And if you’re using VNC or RDP for remote installation today, would this replace them? What would it need to do that it doesn’t yet?

Come talk to us on Matrix (#anaconda:fedoraproject.org), or leave a comment on this article. You can also follow the work on the anaconda-webui GitHub repo. We’re looking forward to hearing from you.

What’s Next for Pagure.io?!

Posted by Fedora Magazine on 2026-06-16 14:59:15 UTC

At the Flock 2026 Birds of a Feather session, poetically named FFFwF (or, for us lazy people, Forging Fedora’s Future with Forgejo), we discussed the current state of our migration effort to the new forge. I asked the obligatory question: Who still has things on pagure.io?!

A few brave contributors raised their hands, some with an uneasy look in their eyes. Miro swiftly pointed out that everybody is affected by one particular repository; looking at you, `fedora-scm-requests`. Luckily, the RelEng folks have it in their sights. Sure, there are a few other repos lying around the old faithful, but it is time for the Fedora Project to move on and embrace the Forge.

Our new home is currently running on the LTS branch in v15.0.2. We are going to stick with it in production, and our next LTS upgrade will be to v19.

What is going to happen next?

Pagure itself as a project is hosted on pagure.io, and that service is going to be decommissioned at the end of July 2026. What does that mean for you? Well, that depends on when you are reading this.

If you just came back from Flock 2026 and you still have active repositories on pagure.io, here is what you need to do:

  • Check out the existing organizations in the Forge. If your project fits into any of the existing ones, ask its owners for a migration.

Some of us have commits in projects that point back to pagure.io. Don’t worry, we are not going to break your links, for foreseeable future. We will explore options for implementing redirects so your historical links successfully point to their current locations.

The best way to handle the transition after your move, right now, is to inform your users about your new home. Add a BIG BOLD ANNOUNCEMENT to your README, close all open issues, and create a single pinned issue with your migration announcement.

Note: Do not expect to be able to log in to pagure.io after July 2026.

Wait… and what about `dist-git`?

Well, that is the next target in the scopes of the Forge team. As I showed you in the room, we have 11 Features that define the transition. The biggest task at hand is a bit more sneaky. We are missing multiple enhancements to the upstream project that will require a lot of coordination and Go code. So, if you find yourself in possession of spare cycles and a particular need to help us make it better and faster, Forgejo is waiting for you!

A road-map with all the tasks for the move will land in the Forge soon. (See resource list below.)

Important Links & Resources

  • Check out the new home: Browse existing organizations on the new Fedora Forge
  • Want to write some Go? Contribute to the upstream Forgejo project.
  • Track our progress: Migration roadmap will be posted here soon

AI Disclaimer: Grammar and formatting were done with the help of robots; all the original brain-farts are my own.

From Contributor to Outreachy Intern: My Fedora Journey Begins

Posted by Fedora Community Blog on 2026-06-16 12:00:00 UTC

Introduction

Hi, I’m Aman, a software developer and open-source enthusiast who enjoys backend development, APIs, and building tools that are useful to others.

I recently started my Outreachy internship with the Fedora community, and this is my first blog as an intern. In this post, I want to share what my first two weeks have been like, what I’ve learned so far, and what I’m looking forward to in the next phase of the internship.

I’m working on the Fedora Release Schedule Planner API, a project focused on improving Fedora’s release planning workflow by moving away from older XML-heavy processes and strengthening the current FastAPI-based API through better tests, authentication, and infrastructure integration.

About the Fedora Community

Fedora is a global open-source community behind Fedora Linux and many related projects. People contribute in many areas, including packaging, infrastructure, design, documentation, testing, and release engineering.

One thing I’ve enjoyed learning about Fedora is its Four Foundations: Freedom, Friends, Features, and First. These values reflect Fedora’s focus on free and open-source software, community, innovation, and adopting new technologies early.

What I like about Fedora is that it is not only about writing code. Communication, documentation, reviews, and helping new contributors are also important parts of the community.

Through this internship, I’m also getting a better understanding of Fedora’s release process and how different contributors work together to improve the tools used by the community.

About My Project

My Outreachy project is Enhancing the Fedora Release Schedule Planner API.

Fedora’s traditional release planning workflow relied heavily on manually edited XML files, which made the process difficult for newcomers, harder to scale, and less connected to modern tooling.

The Fedora Release Schedule Planner API is a modern FastAPI-based project hosted on Codeberg. It has already moved from Flask to a modular FastAPI architecture, uses Pydantic for data validation, provides auto-generated Swagger documentation, and relies on Forgejo Actions for CI/CD testing.

The goal of my internship is to help make this API more production-ready. My work will focus on improving the test suite, strengthening CI reliability, adding secure authentication with OpenID Connect, integrating the API with Fedora infrastructure data, and preparing it for deployment.

Learning More About the Community

I had already started contributing to the Fedora Release Schedule Planner API during the Outreachy contribution period. During that time, I joined the project’s Matrix chat, went through issues and pull requests, and became familiar with the basic project structure.

So, during the first two weeks of the internship, my focus was more on understanding the project in depth. I followed discussions in the Matrix chat, worked through issue and pull request conversations, and learned how mentors and maintainers review changes.

We also have a weekly Google Meet call with the mentors. These calls are helpful for discussing progress, asking questions, and understanding what to focus on next.

Alongside exploring the codebase, I spent time reading Fedora documentation and project-related resources to better understand the release planning workflow.

I also explored the FastAPI codebase, tests, CI setup, and previous pull requests more closely. This helped me understand how tools like Pydantic, Swagger documentation, and Forgejo Actions are being used in the project.

Challenges and Wins

One of my biggest challenges in the first two weeks was understanding the codebase beyond its basic structure. During the contribution period, I had already become familiar with the main parts of the project, but during the internship, I started understanding how different layers work together, including API routes, database models, Pydantic schemas, services, templates, and tests.

Another challenge was making sure my changes did not affect existing behavior. I had to run tests, check formatting, and verify things locally before updating a pull request.

My biggest win was becoming more confident with the project workflow. I was able to work on issues, raise pull requests, respond to review feedback, and understand the expectations around code quality and maintainability.

I also became more comfortable with the tools used in the project, including FastAPI, SQLAlchemy, Pydantic, Jinja2, HTMX, tests, and CI checks.

A small win for me was getting some of my pull requests merged. For example, PR #425 and PR #427 helped me understand the review process better and gave me more confidence while working on the project.

Plans for the Next Month

In the next month, I want to continue building on the work from the first few weeks. Currently, we are focusing on fixing UI-related issues, improving the code structure, and aligning the codebase with the project’s expected structure.

Along with that, I want to keep improving the test suite and make sure the API works correctly with the current FastAPI and Pydantic structure.

I also want to start preparing for the authentication part of the project. Since OpenID Connect is an important goal of this internship, I plan to spend time understanding how Fedora authentication works and how it can fit into the Release Schedule Planner API.

After that, I want to gradually learn more about how this API can connect with Fedora infrastructure data. This is important because the long-term goal of the project is to move away from the older XML-based workflow and make the release planning process more modern and maintainable.

Conclusion

These first two weeks have helped me understand the project better. I now have a clearer understanding of the Fedora community, the Release Schedule Planner API, and how people collaborate in open source.

I still have many things to learn, but I feel more comfortable with the project now than I did at the beginning of the internship.

I am thankful to Outreachy, Fedora, and my mentors for this opportunity, and I am looking forward to continuing the work in the coming weeks.

PS: Cover image generated with the help of an AI tool.

The post From Contributor to Outreachy Intern: My Fedora Journey Begins appeared first on Fedora Community Blog.

Sandbox AI coding agents with microVMs on Fedora Linux

Posted by Fedora Magazine on 2026-06-15 08:00:00 UTC

AI coding agents such as Claude code or Codex get more capable every month. This is great for productivity, but approving all commands gets annoying really quickly. On the other hand, allowing agents to run any command on your work machine is not a great idea. They are really good at exploring your production cluster using kubectl or running remote commands at your production servers over SSH.

Fortunately, Linux distributions come with plenty of options for process isolation. You can run agents as a completely different user, in a container, or in a VM. This article shows how to use microVMs to run coding agents.

Security concerns

Running AI agents in unattended mode is like running untrusted code. Companies behind these agents, such as Anthropic or Google, are not trying to steal credentials, but people keep coming up with new attack vectors like Slopsquatting or prompt injections virtually anywhere.

The coding agents themselves ship with built-in mitigations that try to refuse prompt injections as described, for example, here.

Lightweight sandboxing technologies are another layer of defense in coding agents. On Linux, bwrap is one of the possible implementations. This raises the bar, yet sandbox escapes are still a problem. Take a look at CVE-2026-39861 as an example of multi-platform sandbox escape.

You could use containers to isolate the agent in their own namespace, but they still share the host kernel. Some of the the recent kernel vulnerabilities resulted in privilege escalation (switching from regular user to root) suggesting that containers are not enough as a security boundary.

In the rest of this article, I describe how to use microVMs to easily sandbox coding agents on your Fedora Linux.

Exploring microVMs

First of all, let’s take a look at what microVMs are. Just like any VM, they have their own kernel, one per each microVM. Compared to traditional VMs they start in very short time (hundreds of milliseconds) but don’t offer all the features of full VMs.

This article explains usage of krun runtime for podman. This approach offers the same well-known workflow as containers, but simply runs every container as a microVM.

Start by installing the runtime:

dnf install crun-krun

To run a microVM, simply run podman with –runtime=krun in your terminal:

podman run --runtime=krun --rm -it fedora:44 /bin/bash

Things to watch out for

A microVM is not a regular container, so a few things might behave differently. First, allocate enough CPU and RAM with krun annotations. The defaults are too small and might result in OOM (Out Of Memory) kills. Second, make sure you have libkrun version >= 1.8. Older versions have a bug which prevents you from pressing Enter in your coding agent. Third, the microVM ignores the USER set in the Dockerfile and always boots as root. Either switch to the correct user manually or put the switch into an entrypoint script.

Case study: sandboxing Claude Code for a Python project

This section outlines a simple setup for a Python project managed by uv. It uses podman-compose to mount the project into the microVM. Compared to containers, this podman compose needs additional annotations for UID/GID translation, SELinux labeling, and HW resources. The final setup is very similar to what you would need for containers.

To install podman compose from official Fedora repositories, run:

dnf install podman-compose

The setup has 3 parts:

  • Dockerfile
  • docker-compose.yaml
  • entrypoint.sh

Dockerfile

As mentioned above, podman with krun runtime still runs containers, but spawns each of them in a microVM. This example container includes uv package manager, claude code and a few additional RPM packages. Define your own container based on your project dependencies and programming language.

Make sure to create an unprivileged user and use it for running the agent.

FROM fedora:44

ARG HOST_UID=1000
ARG HOST_GID=1000

# Create group and user matching host UID/GID
RUN groupadd -g ${HOST_GID} appuser && \
    useradd -u ${HOST_UID} -g ${HOST_GID} -m appuser

RUN mkdir -p /venv && chown appuser:appuser /venv
RUN mkdir -p /home/appuser/.claude && chown appuser:appuser /home/appuser/.claude

USER appuser

# Rarely-changing tooling. Kept above the dnf layer so editing the RPM list
# below does not invalidate (and re-run) these installs.
RUN curl -LsSf https://astral.sh/uv/install.sh | sh && \
    curl -fsSL https://claude.ai/install.sh | bash
USER root

# Frequently-changing RPMs. Kept last so adding a package only rebuilds from here down.
RUN dnf install git make vim free libpq-devel python3-devel gcc -y && \
    dnf clean all

COPY --chown=appuser entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh

USER appuser
WORKDIR /app

# This is needed because entrypoint does not have .local/bin in the PATH
ENV PATH="/home/appuser/.local/bin:$PATH"
ENTRYPOINT ["/entrypoint.sh"]
CMD ["/bin/bash"]

docker-compose.yaml

The compose file defines how to mount the project directory into the microVM. This is where most of the magic happens, because podman needs to translate UID/GID and manage SELinux labels, otherwise the files would not be accessible inside of the microVM or they would end up being owned by a different user.

services:
  claude:
    container_name: project-name-claude
    annotations:
      run.oci.handler: krun
      krun.ram_mib: "4096"
      krun.cpus: "4"
    user: "${HOST_UID}:${HOST_GID}"
    userns_mode: keep-id  # optional, for rootless host
    build:
      context: .
      args:
        HOST_UID: "${HOST_UID}"  # use UID and GID from the host so that files created in the container have correct permissions
        HOST_GID: "${HOST_GID}"
    volumes:
      - ../:/app:U,z  # bind mount your project
      - project-name-venv-cache:/venv:U,z
      - claude-config:/home/appuser/.claude:U,z  # persistent claude credentials/config
    working_dir: /app
    stdin_open: true
    tty: true
    environment:
      - CLAUDE_CONFIG_DIR=/home/appuser/.claude
      - UV_LINK_MODE=copy
      - UV_PROJECT_ENVIRONMENT=/venv/env  # This is inside the cached volume
      - UV_PYTHON_INSTALL_DIR=/venv/python  # So that uv-managed python installations are not in home but cached in /venv
      - TERM=xterm-256color
      - COLORTERM=truecolor

volumes:
  project-name-venv-cache:
  claude-config:
    external: true
    name: claude-config

There are 3 key parts:

  • annotations – these select krun as a runtime and specify HW requirements
  • user and userns_mode – this tells podman to translate UID/GID so that the files created in the microVM end up owned by your user on the host
  • volume labels – z tells podman to relabel the files with a shared SELinux label. Otherwise SELinux would prevent the process inside the microVM from touching the files in the volume. U tells podman to recursively chown all files.

entrypoint.sh

The entrypoint creates a virtual environment for the Python project, because we don’t want dynamic dependencies baked into the container image. It also runs the switch from root to regular user because podman with krun runtime ignores the USER directive from the container.

#!/bin/bash
set -e

echo "Sandbox started as user: $(id -un) in directory: $(pwd)"

if [ "$(id -un)" != "appuser" ]; then
  runuser -u appuser -- uv sync
  echo "Running ${@} as appuser"
  exec runuser -u appuser -- "$@"
fi

uv sync
exec "$@"

Run the setup

First, build the container:

$ HOST_UID=$(id -u) HOST_GID=$(id -g) podman-compose -f .agent-sandbox/docker-compose.yaml build
STEP 1/18: FROM fedora:44
...
Successfully tagged localhost/agent-sandbox_claude:latest

Then create the external volume and run the claude container interactively:

$ podman volume create claude-config
$ HOST_UID=$(id -u) HOST_GID=$(id -g) podman-compose -f .agent-sandbox/docker-compose.yaml run --rm claude
Sandbox started as user: root in directory: /app
Resolved 3 packages in 6ms
Checked 3 packages in 1ms
Running /bin/bash as appuser
tty: ttyname error: Inappropriate ioctl for device
[appuser@3bd1234b9a77 app]$

You can now check that the kernel is different by running uname -a inside of the microVM.

Putting it together: single script to create the whole setup

Creating the same setup manually for every project is not the greatest user experience, but you can automate the setup using a simple script like this. It installs a new sbx command that wraps the setup described above into 3 simple command options: init, build, and run.

A word of caution — microVM is not a bulletproof boundary

A microVM raises the bar considerably, but it is not perfect isolation, and it would be irresponsible to present it as such. Take a look at the libkrun git repository to read more about the security model.

If you want to run software that might be dangerous, prefer using a full VM or even cloud VM.

Conclusion

MicroVMs seem like a sweet spot for running AI Agents. They provide a familiar workflow of containers, but the agents run on their own kernel behind a hypervisor. This article describes workflow based on podman and krun runtime because Fedora Linux ships both of them natively, but there are plenty of other options available for any platform (for example dockersandbox).

Note about AI usage: I wrote this article myself. I used Claude (Anthropic) to significantly refine the grammar, wording, and sentence structure; the technical content and all claims are my own and tested.

F44 Election Results

Posted by Fedora Community Blog on 2026-06-13 16:16:29 UTC

The F44 election cycle has concluded. Below are the results. We are posting the results early this year as we are currently on the eve of Flock to Fedora 2026 and the results were ready. Thank you to all candidates and voters, and congratulations to the newly elected members!

Results

Council

Two Council seats were open this election. A total of 204 voters participated in this election.

# votesCandidate
958Miro Hrončok
788Aleksandra Fedorova
744Fabio Valentini
637Tomáš Hrčka
509Vít Smolík
451Akashdeep Dhar
337Hristo Marinov

FESCo

Five FESCo seats were open this election. A total of 199 voters participated in this election

# votesCandidate
771Neal Gompa
700Fabio Valentini
662Michel Lind
604Maxwell G
549Simon de Vlieger
537Adam Miller

Mindshare

Four Mindshare seats were open this election. A total of 154 voters participated in this election.

# votesCandidate
419Samyak Jain
396Akashdeep Dhar
395Luis Bazan
351Mat H (Mat Holmes)
214Kenz S (Makenzie Stewart)

EPEL Steering Committee

Four EPEL Steering Committee seats were open this election. As the amount of interviews submitted equaled the number of open seats, candidates who interviewed were automatically elected.

# votes
Candidate
Automatically ElectedCarl George
Automatically ElectedDiego Herrera
Automatically ElectedJonathan Wright
Automatically ElectedTroy Dawson

The post F44 Election Results appeared first on Fedora Community Blog.

Justin Wheeler on Growing Up in the Fedora Community

Posted by Fedora Magazine on 2026-06-12 15:53:38 UTC

Flock to Fedora is more than a conference – it’s where the Fedora community comes alive. As part of the In the CommitHistory campaign, we sat down with confirmed Flock 2026 speakers to hear their stories: what brought them to Fedora, what Flock means to them personally, and what they’re hoping for in Prague this June. This is one of those conversations.

In 2015, an 18-year-old student walked into his first Flock not knowing a single person. He was shy, a little overwhelmed, and had no idea what he was walking into. By the time he walked out, something had shifted. The community had been so genuinely welcoming, so warm and easy to fall into that he left not just curious about Fedora, but hungry to be part of it.

That student was Justin Wheeler. And Flock never really let him go.

What started as one conference became a thread running through his entire open source journey. First he became a Fedora Magazine author. Then editor-in-chief. And now, as Fedora Community Architect, he’s the one standing on stage at the opening and closing looking out at the very kind of room that once changed his life helping shape the event that shaped him.


He’ll be the first to admit it’s a lot. “It’s way more intense and hard work than I ever could have realized,” he says, with genuine respect for everyone who built Flock before him. But that experience of once being the nervous newcomer gives him something no job description could have: an instinct for why people show up and what makes it matter.

For Justin, the answer has always been the hallway track. Not the sessions, the spaces in between them. The moment you bump into the exact person you need to talk to. The lunch conversation that turns into a collaboration. The game night and candy swap where the ice finally breaks and people stop being usernames and start being friends. “It’s the relationships we get to strengthen and build,” he says, “that make us so much more effective in everything we do the rest of the year.”

That’s also what data can’t capture and Justin thinks about this a lot as part of the Data Working Group, where he works alongside Michael Winters and Robert Wright to understand community health. Numbers can tell you a lot. But they can’t show you a first-timer lighting up when they realise they belong here. They can’t measure the moment the community becomes real.

His advice for anyone walking into Flock for the first time? “Don’t be shy. Leave your comfort zone a little. And definitely don’t skip the social events.” He says it like someone who knows exactly what it feels like to need that push and exactly what’s waiting on the other side of it.

Flock to Fedora 2026 takes place June 14–16 in Prague. Registration is at capacity but you can join the waitlist. Can’t make it in person? Follow along live on the Fedora YouTube channel.We hope to see you there!

What you need to know about the Microsoft Secure Boot certificate expiration: Don’t Panic!

Posted by Fedora Magazine on 2026-06-11 08:00:00 UTC

UEFI Secure Boot keys, used to sign the first stage boot loader, are expiring in June 2026 (this month!) But that only means that Microsoft can no longer sign with them. Machines, both bare metal and virtual, will continue to boot long after June is over as long as the current public keys are not removed from the firmware database or revoked via the dbx database. In the meantime, Fedora Rawhide (f45) already contains a first stage boot loader that is signed by multiple keys for maximal compatibility. So there is no need to panic, but action is recommended.

Secure Boot basics

UEFI Secure Boot is a security feature which ensures only trusted (signed) applications run during a computer’s boot up process. This applies to the boot loaders, the operating system kernel, and the kernel modules. Trust is established using asymmetric cryptography. Tested algorithms, like RSA or ECDSA, are used to create asymmetric key pairs. The private key is used to sign the application. A totally different but complementary public key is used to verify the application. The private key is kept secret while the public key is available to anyone who wants to run the application. UEFI Secure Boot is only available for machines that run UEFI firmware, and for Fedora, the key expiration only applies to the x86_64 architecture (Intel, AMD), and to those who have Secure Boot enabled.

The root of trust for Secure Boot is in the firmware. Hardware manufacturers add trusted Secure Boot public keys to their devices’ Secure Boot firmware database (db). Firmware for virtualization, known as edk2-ovmf, is built with similar trusted public keys. In order to simplify the process, there is a central signing authority which signs the first stage boot loader. This is the “shim” whose public key is enrolled pretty much everywhere, and that is Microsoft. Microsoft first started signing shim with their 2011 UEFI Third Party CA, but by the end of June they will no longer be able to do so. Since October 2025, Microsoft began signing with a new 2023 key as well. Once the 2011 key expires, new shims will only be signed with the 2023 key.

The OS maintains the rest of the Secure Boot chain. Fedora’s shim embeds a Fedora Secure Boot public CA key. Private keys on Fedora’s signing server are used to sign the next stage boot loader (grub2), the kernel, and any other applications that need to run during the boot process (like fwupd for firmware updates or unified kernel images– UKIs)

When the kernel is built, kernel modules are signed using an ephemeral key. Only signed kernel modules can be loaded when Secure Boot is enabled.

Action Recommended

The fact is that you don’t really have to do anything about any of this right now. Your computer will continue to boot. New installations of both older and new OSes will continue to be possible.

BUT, we recommend updating your Secure Boot database if and when an update is available. The next deliverable shim update can only be signed by the 2023 key and it is best to be prepared. While there are no known exploitable security vulnerabilities in shim at this time, new ones may be found next month or next year. Below are some commands that will help you determine what state your computer is in, and how to make the correct updates.

How to tell if you have UEFI or legacy BIOS

The presence of the /sys/firmware/efi directory is the clearest way to check whether you are running UEFI firmware or legacy BIOS. The following command will print “BIOS” if the efi directory does not exist:

$ [[ -d /sys/firmware/efi ]] || echo BIOS

How to check if Secure Boot is enabled

$ mokutil --sb-state
SecureBoot enabled

The Secure Boot state may be “enabled”, “disabled”, or the machine may be in “Setup Mode”, which means there are no Secure Boot keys enrolled in firmware.

How to identify which keys are in the firmware db

$ mokutil --db --short
580a6f4cc4 Microsoft Windows Production PCA 2011
45a0fa3260 Windows UEFI CA 2023
46def63b5c Microsoft Corporation UEFI CA 2011
b5eeb4a670 Microsoft UEFI CA 2023

This output is from a VM, and as you can see, it already contains the 2011 and 2023 public keys. Your laptop or desktop will also show other database keys from the manufacturer.

How to update the firmware db

Enable and use fwupd to get your updates from the Linux Vendor Firmware Service (LVFS):

$ sudo fwupdmgr update

If you have an HP or Fujitsu machine, the update will be available soon, after you have updated your firmware. Use either the above command, or the vendor-recommended command at that time.

How to check which key(s) signed the shim

$ sudo dnf install pesign -y
$ sudo pesign -S -i /boot/efi/EFI/fedora/shimx64.efi
----------------------------------------------
certificate address is 0x7f3fffc11410
Content was not encrypted.
Content is detached; signature cannot be verified.
The signer's common name is Microsoft Windows UEFI Driver Publisher
No signer email address.
No signing time included.
There were certs or crls included.
----------------------------------------------
certificate address is 0x7f3fffc139e0
Content was not encrypted.
Content is detached; signature cannot be verified.
The signer's common name is Microsoft UEFI CA 2023 signer
No signer email address.
No signing time included.
There were certs or crls included.
-----------------------------------------------

The output shown here is from the dual-signed Fedora Rawhide (F45) shim. If Rawhide is not installed, the shim will only be signed with the first key, which is the 2011 key.

You can use the same pesign command to examine grub2 (/boot/efi/EFI/fedora/grubx64.efi) and the kernel (/boot/vmlinuz-…).

What NOT to do

If a database update is not available for your system, contact your hardware manufacturer. Do not attempt to force an incompatible update. Do not update your database manually unless you know exactly what you are doing!

Do not remove or revoke the 2011 key. The 2011 key is not compromised, it is only expiring, so there is no need to remove it. Additionally, it was used to sign option ROMs, so removing it could render peripherals on your system inoperable. Likewise, adding the 2011 key to the firmware dbx database (the forbidden database) will affect option ROMs. This will stop the dual-signed shim from booting.

New badge: Czech Mate! !

Posted by Fedora Badges on 2026-06-11 05:35:14 UTC
Czech Mate!You joined the party at Flock 2026 in Prague!

Network issues

Posted by Fedora Infrastructure Status on 2026-06-10 13:00:00 UTC

Switch upgrades were done this morning, and something has gone wrong with them. Networking engineers are working on restoring full service.

ipv6 access to some of our services is impacted, along with possible slowdowns in other services.

Jaroslav Reznik on Security, the EU Cyber Resilience Act, and Why You Can’t Do Things From Behind a Desk!

Posted by Fedora Magazine on 2026-06-10 08:00:00 UTC

Flock to Fedora is more than a conference – it’s where the Fedora community comes alive. As part of the In the CommitHistory campaign, we sat down with confirmed Flock 2026 speakers to hear their stories: what brought them to Fedora, what Flock means to them personally, and what they’re hoping for in Prague this June. This is one of those conversations.

Jaroslav Reznik has been part of Fedora longer than most people remember. This goes all the way back to Red Hat Linux 5, before Fedora was even known as Fedora. After a brief detour to another distro, he joined the KDE SIG days and went on to build a long career in Red Hat’s Program Management team. But it was the EU Cyber Resilience Act (CRA) that brought him back to the Fedora community.

The moment that changed everything? A scene at FUDCon North America in 2009 watching Fedora’s Program Manager command what looked like a sci-fi control room, scheduling Fedora 13. Jaroslav looked at that and thought: I want that job. Years later, he got it.

On the CRA, Jaroslav is clear and passionate. The regulation is the first to formally acknowledge the existence of open source software in legislation. Thanks to an enormous community effort, it’s actually open-source friendly. Non-commercialised community projects are fully exempt. For a project like Fedora, the concept of open-source stewards formally recognised in the regulation opens up a powerful new model for governance.

The program management team is working to build a stewardship governance model around Fedora. They are making it a welcoming place for anyone who wants to support the project. They are clear about what stewardship should and shouldn’t be: it’s not about monetizing open source or adding burdens, it’s about helping the community raise the bar for security together.

Flock holds a special place for Jaroslav; he co-organised the very first Flock held in Prague back in 2014. Now, more than ten years later, he is returning to Prague for Flock 2026 with Roman Zhukov to not only talk about the CRA but run a hands-on workshop on it. His message is simple: you can’t do things from behind a desk.

Flock to Fedora 2026 takes place June 14–16 in Prague. Registration is at capacity but you can join the waitlist. Can’t make it in person? Follow along live on the Fedora YouTube channel.We hope to see you there!

Note: AI (Google Gemini) was used in drafting this article. The content was reviewed and verified before publishing.

Onboarding a Forgejo-hosted project to Fedora Konflux

Posted by Fedora Community Blog on 2026-06-09 09:08:39 UTC

We, the Forge team, recently onboarded a Codeberg-hosted repo to the new Fedora Konflux instance.
This is a guide based on the onboarding experience, the steps and UI are similar in Fedora’s Forge.

Useful links

Step 1: Get access to the tenants-config GitLab repo

Konflux configuration is managed through GitOps in the
tenants-config
repo on GitLab. The UI is intended to be read-only — you should do everything through merge requests.

  • Sign in via SAML SSO at https://gitlab.com/groups/fedora/-/saml/sso to get
    group membership.
  • Make sure you have at least a Guest role. Guest lets you approve MRs
    but not merge them. Ask a maintainer to bump your role if needed.
  • Get yourself added to CODEOWNERS for your tenant’s directory
    Example MR.

Step 2: Create your tenant namespace

Konflux namespace.

Follow the instructions in the
tenants-config repo:

  • Run the create-tenant-resources playbook. It generates the namespace, RBAC
    and quota resources.

You end up with three files:

  • ns.yaml — the namespace with a konflux-ci.dev/type: tenant label
  • rbac.yaml — a RoleBinding granting konflux-admin-user-actions to your FAS
    user
  • kustomization.yaml — ties together the quota, RBAC, namespace and your
    applications directory. Quota can be increased later.

Then run the update-tenant-apps playbook to generate an ArgoCD application
manifest per tenant directory and update the ArgoCD kustomization.

Example MR.

Step 3: Define your Applications and Components

Konflux applications.

This is where you tell Konflux what to build. We went with a Kustomize
Configuration-as-Code setup with three layers:

  • A shared base — a generic Component template with the git URL, provider
    annotations (git-provider: forgejo, git-provider-url: https://codeberg.org),
    pipeline config and the build.appstudio.openshift.io/request: configure-pac
    annotation.
  • Per-application bases — an Application CR plus per-variant overrides (e.g.
    rawhide vs. stable).
  • Per-environment overlays (staging/production) — patches for application names,
    component names, context paths and Dockerfile paths.

Open a merge request with everything
Example MR.

Step 4: Add ImageRepository resources

Each Component needs a matching ImageRepository CR. If you don’t have one, the image controller
never provisions a Quay repo, spec.containerImage stays empty on the
Component, and the build service just sits there waiting. No webhook, no PaC PR,
nothing happens.

Example ImageRepository:

apiVersion: appstudio.redhat.com/v1alpha1
kind: ImageRepository
metadata:
  name: forge-rawhide-production
  namespace: fedora-infra-tenant
  annotations:
    image-controller.appstudio.redhat.com/update-component-image: "true"
  labels:
    appstudio.redhat.com/application: forge-production
    appstudio.redhat.com/component: forge-rawhide-production
spec:
  image:
    name: fedora-infra-tenant/forge-rawhide-production
    visibility: public

The update-component-image: "true" annotation is what tells the image
controller to write the Quay URL back to spec.containerImage on the Component.

Example MR. Do not merge yet.

Step 5: Create the SCM secret

Konflux needs a secret to authenticate with your Forgejo/Codeberg instance:

oc create secret generic pipelines-as-code-codeberg 
  -n {namespace} 
  --type=kubernetes.io/basic-auth 
  --from-literal=password={FORGEJO_TOKEN}

oc label secret pipelines-as-code-codeberg -n {namespace} 
  appstudio.redhat.com/credentials=scm 
  appstudio.redhat.com/scm.host=codeberg.org

The Konflux docs
say you need these token scopes:

  • issue: Read and Write
  • organization: Read
  • repository: Read and Write
  • user: Read

Don’t restrict the token to a specific repo — scopes like write:user aren’t
available with repo-scoped tokens on Forgejo. If you set the right scopes and
it still complains about insufficient permissions, try a token with everything
enabled.

Step 6: Merge and verify

With the secret in place, merge your MR. ArgoCD picks it up and syncs the
resources. Wait a few minutes, then check:

# Did containerImage get set?
oc get components -n {namespace} 
  -o custom-columns='NAME:.metadata.name,IMAGE:.spec.containerImage'

# Are the ImageRepositories ready?
oc get imagerepositories -n {namespace} 
  -o custom-columns='NAME:.metadata.name,STATE:.status.state'

# What does the PaC status say?
oc get components -n {namespace} 
  -o custom-columns='NAME:.metadata.name,STATUS:.metadata.annotations.build.appstudio.openshift.io/status'

If spec.containerImage is filled in and the status shows "state":"enabled",
you’re good.

Step 7: Handle the PaC pull requests

Konflux opens pull requests on the source repo.

At this point Konflux opens PRs on your source repo with auto-generated Tekton
pipeline files in .tekton/. Two ways to go:

  • Merge them as-is if you’re happy with Konflux’s defaults.
  • Close them and use your own pipelines. If you already have .tekton/ files,
    update them with:
  • application/component labels matching your Konflux component names
  • output-image pointing to quay.io/redhat-user-workloads/{namespace}/{component}
  • latest task bundle versions (grab the @sha256:... refs from the
    Konflux-generated files)
  • serviceAccountName: build-pipeline-{component}

We went with the second option. We already had pipelines with custom version
tagging that we wanted to keep, so we pulled in the new task bundles and labels
from the generated files and left the rest alone.

Step 8: Re-triggering when things go wrong

The configure-pac annotation gets consumed on the first attempt. If it fails
(token issue, rate limit, whatever), you need to re-add it:

# One component
oc annotate component {component} -n {namespace} 
  build.appstudio.openshift.io/request=configure-pac --overwrite

# All of them
for comp in $(oc get components -n {namespace} -o name); do
  oc annotate $comp -n {namespace} 
    build.appstudio.openshift.io/request=configure-pac --overwrite
done

To sum it up, we created a tenant on Konflux-ci cluster, created applications and components and set a place where the images would be hosted. At the event of push to the codeberg repo main branch – the repo where we store the Forge Containerfiles, the pipeline gets triggered (scoped by the on-cel-expression to only those contexts where the change happened) and a fresh and tagged image appears on quay, ready for further testing and deployment.

Thanks to the Konflux Team for the Forgejo support!

The post Onboarding a Forgejo-hosted project to Fedora Konflux appeared first on Fedora Community Blog.

Peter Boy on Why Fedora Needs More Than Just Technical Contributors

Posted by Fedora Magazine on 2026-06-09 08:00:00 UTC

Peter Boy came to Fedora documentation the way many contributors do, by seeing a gap and deciding to fill it. As a researcher, writing is his daily work. When he looked at how he could meaningfully contribute to Fedora, documentation was the obvious answer. He started with Fedora Core 1, stepped away, and returned in 2020 when both the Server Working Group and the Docs Team were being revitalised at the same time. Since then, his focus has been on the “bigger-picture” content structure, readability, consistency, and inspiring others to get involved.

His first Flock was in Cork, Ireland in 2023, and what struck him most was the collaborative approach combined with open, structured dialogue and the sheer range of personalities all genuinely trying to get to know each other.


For a team like Docs, where so much depends on shared standards and careful communication, Peter sees Flock as irreplaceable. New ideas emerge from spontaneous conversation, something the formal structure of video calls simply can’t replicate. His message to anyone thinking about contributing? Fedora needs far more than technical contributors. Documentation, communication, community building these are all vital, and Fedora needs to do a better job of making that visible. At Flock 2026, he is most looking forward to the working groups and the hallway conversations, the ones that are simply too nuanced to have any other way.

Flock to Fedora 2026 takes place June 14–16 in Prague. Registration is at capacity but you can join the waitlist. Can’t make it in person? Follow along live on the Fedora YouTube channel.We hope to see you there!

Note: AI (Google Gemini) was used in drafting this article. The content was reviewed and verified before publishing.

Jona Azizaj – Why Mentorship at Flock Changes Everything!

Posted by Fedora Magazine on 2026-06-08 08:00:00 UTC

Flock to Fedora is more than a conference – it’s where the Fedora community comes alive. As part of the CommitHistory campaign, we sat down with confirmed Flock 2026 speakers to hear their stories: what brought them to Fedora, what Flock means to them personally, and what they’re hoping for in Prague this June. This is one of those conversations.

Jona Azizaj’s first Flock was ten years ago in Kraków, Poland. What struck her most was how approachable everyone was. In a community full of experienced contributors, people made space for new voices, listened to her experiences building the local community in Albania, and made her feel like her perspective genuinely mattered. Those small moments, she says, are what made her feel like she truly belonged.

A decade on, Jona sees Flock as one of the most powerful tools for growing the next generation of Fedora contributors. Online mentorship happens asynchronously and at a distance. Flock, however, creates something different: the chance to sit down with someone, share experiences, and build real trust. Flock is where contributors grow more confident, find their place, and realise that open source is about far more than technical work.

For Flock 2026, Jona and the Fedora Mentor Summit team are bringing three initiatives, now in their 5th edition.

A successful Flock, for Jona, is one where people leave feeling more confident than when they arrived. It is an event where the connections built there carry on long after the event ends.

Flock to Fedora 2026 takes place June 14–16 in Prague. Registration is at capacity but you can join the waitlist. Can’t make it in person? Follow along live on the Fedora YouTube channel.We hope to see you there!

Note: AI (Google Gemini) was used in drafting this article. The content was reviewed and verified before publishing.

Akashdeep Dhar – Contributing to Fedora Infrastructure and the Power of Flock!

Posted by Fedora Magazine on 2026-06-05 15:07:06 UTC

Flock to Fedora is more than a conference – it’s where the Fedora community comes alive. As part of the In the Commit History campaign, we sat down with confirmed Flock 2026 speakers to hear their stories: what brought them to Fedora, what Flock means to them personally, and what they’re hoping for in Prague this June. This is one of those conversations.

Akashdeep’s history with Flock goes back around five years, and his perspective on it has evolved significantly. During his time on the Fedora Council, he participated in the grueling process of reviewing over 150 talk proposals in a single cycle. This task was made harder by the fact that acceptance is often tied to sponsored travel meaning funding rejection can mean a contributor simply can’t attend at all.

But beyond the sessions and schedules, Akashdeep is emphatic about what Flock is really for. Roughly 75% of the experience is about human connection; understanding the person behind the screen, building friendships, and embodying the “friends foundation” philosophy at the heart of Fedora. Technical work is the bonus, not the point.

Nowhere is this clearer than in the story of the Fedora Badges revamp. Interest in rebuilding the platform which, despite its 2003-era interface, plays a vital role in motivating new contributors, dates back to 2019. But it was Flock’s hallway conversations and dedicated workshops that finally built the consensus needed to move the project forward.

Akashdeep also wants people to know that contributing to Fedora infrastructure is more accessible than it looks. You don’t need to be on a specific team or work for a particular company. Just join a chat, introduce yourself, and find your corner. As one contributor discovered, starting with documentation led to a whole journey into diversity and inclusion work. Community bonding is what keeps people, and the technical work is the reward.

Flock to Fedora 2026 takes place June 14–16 in Prague. Registration is at capacity but you can join the waitlist. Can’t make it in person? Follow along live on the Fedora YouTube channel.We hope to see you there!

Note: AI (Google Gemini) was used in drafting this article. The content was reviewed and verified before publishing.

Community Update – Week 23 2026

Posted by Fedora Community Blog on 2026-06-05 10:00:00 UTC

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: 01 – 05 June 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

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

RISC-V

This is the summary of the work done regarding the RISC-V architecture in Fedora.

  • F44: core rebuild is completed. Image generation and repo-creation needs some work. ‘omni’ kernels are being built and  ‘kiwi descriptions’ (required for image generation) needs some RISC-V specific patching.  We’re short on resources , so this delay is expected.
  • Conferences preparation:
    • Prep for RISC-V Summit, meetings with hardware vendors, upstream meetings, and RISE 
    • Prepare updated material for Flock RISC-V update
  • [Hardware] We have one of the newest RVA23 boards (SpacemiT K3) in Fedora RISC-V Koji.
    • Thanks to Jason Montleon.  It’s his personal hardware.   A CLE-sponsored Fedora K3 builder is on its way to him too, it’ll be wired into RISC-V Koji
  • [Hardware] Discussed with Jefro about potentially working with Scaleway to get some cloud builders via the RISE initiative.  To be discussed at the RISC EU Summit.

AI

This is the summary of the work done regarding AI in Fedora.

  • t0xic0d3r helped draft the Fedora AI Developer Desktop Community Objective logic model [Draft]

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.

Forgejo

This team is working on introduction of https://forge.fedoraproject.org to Fedora
and migration of repositories from pagure.io.

  • Discussed the coordination process for the private issues
  • Enabled the members team to create repositories [Access]

EPEL

This team is working on keeping Epel running and helping package things.

  • Prepared EPEL 10.1 for move to archives
  • Package maintenance across multiple Fedora and EPEL packages
  • Quality work via bug reports and bodhi karma
  • Starting to onboard Pedro

UX

This team is working on improving User experience. Providing artwork, user experience,
usability, and general design services to the Fedora project

  • Finalizing Flock materials
    • Everything for print sent to organisers
    • Digital assets is now the focus

If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.

The post Community Update – Week 23 2026 appeared first on Fedora Community Blog.

New badge: Flock 2026 Attendee !

Posted by Fedora Badges on 2026-06-05 00:22:08 UTC
Flock 2026 AttendeeYou attended Flock 2026, the Fedora contributor conference, in Prague, Czech Republic

Updates and reboots on Fedora infrastructure

Posted by Fedora Infrastructure Status on 2026-06-04 21:00:00 UTC

Fedora Infrastructure team will be applying updates to servers and rebooting them.

Many services will be affected, most should only be down for a short time as their particular resources are rebooted HOWEVER some may be down for a non-trivial amount of time due to RHEL-9 to RHEL-10 upgrades.

In …

Aleksandra Fedorova on Community, Flock, and the Human Side of Fedora

Posted by Fedora Magazine on 2026-06-04 08:00:00 UTC

Flock to Fedora is more than a conference — it’s where the Fedora community comes alive. As part of the #In the CommitHistory campaign, we sat down with confirmed Flock 2026 speakers to hear their stories: what brought them to Fedora, what Flock means to them personally, and what they’re hoping for in Prague this June. This is one of those conversations.

Aleksandra Fedorova’s journey into Fedora started with a sticker. At LinuxTag in Berlin, her first properly organised Linux community event she approached the Fedora booth simply wanting a sticker. What happened next changed everything. The people behind the booth invited her to join them on their side of the table. That single gesture dismantled the wall between user and contributor, and she never looked back.

For Aleksandra, Flock isn’t the place for deep technical work. Instead, it’s where the Fedora Council reads the room, sensing priorities, spotting coordination gaps, and picking up on tensions before they become real problems. She’s also refreshingly honest about Flock’s limitations: the costs of attending mean it’s not always a fully representative cross-section of the community, and understanding the broader Fedora ecosystem requires deliberate effort beyond the event itself.

But what Flock offers that nothing else can? The human element. No mailing list or Matrix channel lets you simply walk up to someone and start a conversation without a formal introduction. At Flock, the hallway is as valuable as the schedule. For Flock 2026, Aleksandra hopes the event helps ease current tensions; the reminder that everyone is working toward the same goal, even when they disagree on how to get there, is something only being in the same room together can provide.

Flock to Fedora 2026 takes place June 14–16 in Prague. Registration is at capacity but you can join the waitlist. Can’t make it in person? Follow along live on the Fedora YouTube channel.We hope to see you there!

Note: AI (Google Gemini) was used in drafting this article. The content was reviewed and verified before publishing.

Fedora 43 Upgrade revealed 20 years old Outlook Security Bug

Posted by Fedora Magazine on 2026-06-03 19:19:57 UTC

Yes, the Fedora 43 upgrade brought an interesting revelation for all Outlook users—one that Microsoft is unlikely to be thrilled about. Outlook was not encrypting email connections, even though SSL/TLS was clearly enabled in the account settings. It looks like, that bug dates back to at least Outlook 2007, which is the oldest Outlook version I was informed about.

Let us start with the beginning

Every six months, Fedora Servers require and upgrade to the next release version, as you all know 😉 This May we had to upgrade from 42 to 43 and in this upgrade, Dovecot POP/IMAP server switched to version 2.4.3. Dovecot did us all an unexpected favor, because it required a full rewrite of the used service config, because it’s not backwards compatible. This change introduced a new paradigm: PLAIN TEXT passwords are no longer allowed over unencrypted connections.

This is a major break with the oldest RFCs (i.e. RFC 1081) regarding POP3 behavior, but a good one IMHO. No one should still use unencrypted connections to any form of service on the internet when we have easy to use encryption protocols like STARTTLS (STLS) at hand in any major client.

The Day After

After the upgrade, “we” (admins & customers) did not even know about the now broken auth-mechanism. This came a day later when customers started to call the support line about rquesters popping up for them to enter their passwords again. This is a normal behavior if auth fails… and it failed hard 😉

As all admins know, such upgrades will result in higher amounts of support calls. To my surprise it was all Outlook clients that called. The oldest version so far was Outlook 2007. We even had an old MACOS Outlook :-). They all had in common, that the mailbox prefs had “SSL/TLS” enabled, but used Port 110, which is the old cleartext port for POP3, where port 995 is the correct SSL port. A normal mailclient would change the port number to 995 as soon as you enable SSL/TLS encryption. This is because you can’t “speak” SSL on a non-ssl port, except if you choose STARTTLS. This starts as a cleartext connection, but upgrades itself to ssl-encrypted later.

“Look, there is something out there!”

Outlook did the worst move you can take as a security enhanced app. It silently ignored the choosen SSL option and used the unencrypted port 110 without any notice to the user. After our server upgrade, the following message popped up:

German version of the error message

“-ERR [AUTH] Cleartext authentication disallowed on non -secure ( SSL/TLS ) connections.“ popped up if you tried to open your inbox. The server logs revealed it clearly: the user used a non-secure connection and got this message correctly. This never got noticed since the EU GDRP only states, that corporations and organisations need to protect their data via a transport encryption like TLS. Normal persons don’t need to do so.

Even some of the notable folks of Fedora did not use encryption, which I personally advise to change immediately. Having this in mind, who are we to judge if you encrypt your connection or not? 😉

Really folks: use TLS encryption for your mailboxes!

You can easily check if TLS encryption is working. Send yourself an mail and open the mail headers, you will find lines like this:

Received: from bastion01.fedoraproject.org ([38.145.32.11] helo=bastion.fedoraproject.org)
by s113.resellerdesktop.de with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384
(Exim 4.99.2)
(envelope-from <updates@fedoraproject.org>)
…
Any good MTA ( Exim, Postfix, etc. ) will note if the connection was encrypted or not.

If you don’t see an encryption notice, you can use this command: 

tcpdump -A -n -n port 110 or port 143

in a root terminal and see if the unencrypted port is used for transport. If so, if it’s cleartext or if it’s using STLS.

So… THANKS Fedora 43 and Dovecot 2.4 … you revealed a 20 year old security bug in Outlook \o/

Disclaimer: It is possible that MS patched the Outlook UI in the past in a way that only old accounts are affected by this major fail. As Fedora users we had no Outlook available to test this 😉

Source: https://marius.bloggt-in-braunschweig.de/2026/06/03/outlook-hat-emailverbindung-nicht-verschluesselt/

Valentin Rothberg on Building the Future of Fedora Containers

Posted by Fedora Magazine on 2026-06-03 08:00:00 UTC

Flock to Fedora is more than a conference – it’s where the Fedora community comes alive. As part of the In the CommitHistory campaign, we sat down with confirmed Flock 2026 speakers to hear their stories: what brought them to Fedora, what Flock means to them personally, and what they’re hoping for in Prague this June. This is one of those conversations.

Valentin Rothberg’s journey into container-native Linux didn’t start with a grand plan – it started with the work. After over 8 years at Red Hat contributing to projects like Podman and bootable containers, Fedora felt like the natural home for his next chapter. In Summer 2025 he began working on Project Hummingbird, which builds directly on top of Fedora. Flock 2026 is where he wants to share what he’s learned.

His first Flock was in Budapest in 2019 – and he remembers it vividly. Stepping in at the last minute for Dan Walsh, he ended up presenting for over three hours straight on container technologies. Not a bad way to make an entrance.

For Valentin, Flock’s value isn’t primarily technical. Technical decisions tend to be made comparatively fast once a group of people rally around a cause. What matters is finding that cause together, and in-person time is what makes that possible. The implementation details, he says, are just details.

He’s also refreshingly honest about where Fedora stands in the container ecosystem. Despite being the birthplace of tools like Podman, Fedora containers don’t see wide use outside the community. Valentin has ideas about why, and how to change that. He’s coming to Flock not to present answers, but to hear other perspectives and build something together.

Flock to Fedora 2026 takes place June 14–16 in Prague. Registration is at capacity but you can join the waitlist. Can’t make it in person? Follow along live on the Fedora YouTube channel. We hope to see you there!

Note: AI (Google Gemini) was used in drafting this article. The content was reviewed and verified before publishing.

From Antarctica to FPL : Jef Spaleta on Leading Fedora Into Its Next Chapter

Posted by Fedora Magazine on 2026-06-02 22:40:26 UTC

Flock to Fedora is more than a conference – it’s where the Fedora community comes alive. As part of the “CommitHistory” campaign, we sat down with confirmed Flock 2026 speakers to hear their stories: what brought them to Fedora, what Flock means to them personally, and what they’re hoping for in Prague this June. This is one of those conversations.

Jef Spaleta came back to Fedora at exactly the right moment. After years away, working across software startups and following his spouse’s move back to the east coast, the timing aligned perfectly with the previous project leader stepping down. With a sharpened skill set and fresh perspective, Jef felt ready to lead.

But leading Fedora in 2026 isn’t just about keeping the lights on. Jef sees the project at a critical crossroads. There is a generational transition where original founders are stepping away and institutional knowledge risks disappearing with them. His focus? Mentoring the next wave of contributors to keep Fedora sustainable for the next five to ten years.

On the state of the project, Jef is honest: Fedora continues to ship high-quality releases on schedule, a streak held for five or six years. But stability isn’t enough. He is developing a new Fedora innovation lifecycle, a dedicated space for experimental work where things can be tried, broken, and learned from without disrupting the mature processes the project depends on.

For Jef, Flock’s value is simple but profound. Digital tools work well when everyone agrees, but they fall apart when things get hard. Flock is where relationship repair happens, where tone and intent can finally be communicated in ways text never can. Looking ahead to Flock 2026, he is focusing on two priorities. First, migrating Forge infrastructure to meet the expectations of the next generation of developers, and second, shaping Fedora’s approach to AI-assisted development before the conversation shapes itself.

Flock to Fedora 2026 takes place June 14–16 in Prague. Registration is at capacity but you can join the waitlist. Can’t make it in person? Follow along live on the Fedora YouTube channel. We hope to see you there!

Note: AI (Google Gemini) was used in drafting this article. The content was reviewed and verified before publishing.

#Commit History: Tell Us About Your First Commit

Posted by Fedora Magazine on 2026-06-02 14:11:26 UTC

Maybe it was a one-line typo fix in the docs. Perhaps it was a package you’d been maintaining in secret for months before you finally submitted it. Maybe it was completely terrifying, or maybe it just felt like the most natural thing in the world. Whatever it was we want to hear about it.

Ahead of Flock to Fedora 2026 (June 14–16, Prague), We the Fedora CommOps team are launching #Commit History: a community campaign to collect the origin stories of Fedora contributors – the moments that brought people into this project and kept them here.

The best stories will be featured in a Fedora Magazine article published before Flock 2026, celebrating the people who make this project what it is.

Here are the questions used to get started-

  • What was your first contribution to Fedora – and what made you take that first step?
  • What did it feel like? What went wrong (or right)?
  • Looking back, what did that moment mean for your open source journey?

There are no wrong answers. First commits come in all shapes code, documentation, translations, design, bug reports, community work. If you’ve ever contributed to Fedora, your story belongs here.

How to share: Drop your story in the comments below, or share it on Mastodon with the hashtag #Commit History.

Whether you’ve been contributing for a decade or made your first commit last week – we want to hear from you.

Planned Outage - Fedora Copr - copr-backend upgrade

Posted by Fedora Infrastructure Status on 2026-06-02 09:00:00 UTC

Fedora Copr build queue processing will be stopped during this outage while copr-backend is upgraded to new version.

DNF packages and repositories will remain available.

F44 Elections Vote Now!

Posted by Fedora Community Blog on 2026-06-01 13:39:46 UTC

The F44 elections voting period is now open! The ballot boxes for this cycles elections are open from today, Monday June 1st until Friday, June 12th on the elections app. The ballot boxes will close on June 12th at 23:59:59 UTC.

For links to candidate interviews, please visit this post or the nominations wiki page of each election.

As the number of eligible candidates (4) equaled the number of open seats (4) for the EPEL Steering Committee, no ballot box is available for this election. Instead, these candidates are automatically elected by default.

Good luck to all of our candidates across Fedora Council, FESCo and Mindshare Committee during this election cycle!

The post F44 Elections Vote Now! appeared first on Fedora Community Blog.

F44 Elections Interviews

Posted by Fedora Community Blog on 2026-05-29 23:03:10 UTC

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!

Fedora Council – 2 seats open

Fedora Engineering Steering Committee/FESCo – 5 seats open

Fedora Mindshare Committee – 4 seats open

EPEL Steering Committee – 4 seats

The post F44 Elections Interviews appeared first on Fedora Community Blog.

F44 EPEL Elections: Interview with Jonathan Wright (jonathanspw)

Posted by Fedora Community Blog on 2026-05-29 22:59:20 UTC

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.

The post F44 EPEL Elections: Interview with Jonathan Wright (jonathanspw) appeared first on Fedora Community Blog.

F44 EPEL Elections: Interview with Diego Herrera (dherrera)

Posted by Fedora Community Blog on 2026-05-29 22:56:04 UTC

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.

The post F44 EPEL Elections: Interview with Diego Herrera (dherrera) appeared first on Fedora Community Blog.

F44 EPEL Elections: Interview with Carl George (carlwgeorge)

Posted by Fedora Community Blog on 2026-05-29 22:52:36 UTC

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 Carl George (carlwgeorge)

What is your name and what is your FAS ID?


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.

The post F44 EPEL Elections: Interview with Carl George (carlwgeorge) appeared first on Fedora Community Blog.

F44 EPEL Elections: Interview with Troy Dawson (tdawson)

Posted by Fedora Community Blog on 2026-05-29 22:45:50 UTC

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.

The post F44 EPEL Elections: Interview with Troy Dawson (tdawson) appeared first on Fedora Community Blog.

F44 Mindshare Elections: Interview with Akashdeep Dhar (t0xic0der)

Posted by Fedora Community Blog on 2026-05-29 22:37:26 UTC

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 Akashdeep Dhar (t0xic0der)

  • FAS ID: t0xic0der
  • Matrix Rooms: Fedora Council (#council:fedoraproject.org), Fedora Mindshare (#mindshare:fedoraproject.org), Fedora Forgejo (#fedora-forgejo:fedoraproject.org), Fedora Infrastructure (#admin:fedoraproject.org), Fedora Badges (#badges:fedoraproject.org), Fedora Apps (#apps:fedoraproject.org), Fedora Join (#join:fedoraproject.org), Fedora Mentoring (#mentoring:fedoraproject.org)

Questions

What is your background in Fedora? What have you worked on and what are you doing now?

Since the past year, I have been actively contributing to the event planning [1] [2] and proposal curation in the Mindshare committee. Representing our vested interests in the Fedora Council, I have paved the way for improvements in the regional event support (i.e., event owners and regional inventory), digital ambassadorship (i.e., swagpack designs and social media) and recognition service (i.e., Community Metrics and Fedora Badges).

Besides championing our community presence in underrepresented regions (e.g., in DevConf.IN 2026 and FOSSAsia 2026 in APAC), I have continued staying at the forefront of the Fedora Forge community initiative, working as an infrastructure architect for Fedora Infrastructure applications, organizing Fedora Mentor Summit during Flock events and mentoring budding contributors formally/informally in the community.

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.

The post F44 Mindshare Elections: Interview with Akashdeep Dhar (t0xic0der) appeared first on Fedora Community Blog.

F44 Mindshare Elections: Interview with Mackenzie Stewart (monkeybean12)

Posted by Fedora Community Blog on 2026-05-29 22:33:17 UTC

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.

The post F44 Mindshare Elections: Interview with Mackenzie Stewart (monkeybean12) appeared first on Fedora Community Blog.

F44 Mindshare Elections: Interview with Mat Holmes (theprogram)

Posted by Fedora Community Blog on 2026-05-29 22:27:42 UTC

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.

The post F44 Mindshare Elections: Interview with Mat Holmes (theprogram) appeared first on Fedora Community Blog.

F44 Mindshare Elections: Interview with Samyak Jain (jnsamyak)

Posted by Fedora Community Blog on 2026-05-29 22:25:36 UTC

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.

Since this is mindshare, Samyak wanted to do something innovative and creative for keeping mindshare spirit alive.

Samyak Mindshare Election Campaign

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.

The post F44 Mindshare Elections: Interview with Samyak Jain (jnsamyak) appeared first on Fedora Community Blog.

F44 Mindshare Elections: Interview with Luis Bazan (lbazan)

Posted by Fedora Community Blog on 2026-05-29 22:23:16 UTC

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.

The post F44 Mindshare Elections: Interview with Luis Bazan (lbazan) appeared first on Fedora Community Blog.

F44 Council Elections: Interview with Miro Hrončok (churchyard)

Posted by Fedora Community Blog on 2026-05-29 21:42:06 UTC

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.

The post F44 Council Elections: Interview with Miro Hrončok (churchyard) appeared first on Fedora Community Blog.

F44 Council Elections: Interview with Tomáš Hrčka (humaton, jednorozec)

Posted by Fedora Community Blog on 2026-05-29 21:41:15 UTC

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 Tomáš Hrčka (humaton, jednorozec)

  • FAS ID: humaton, jednorozec
  • Matrix Rooms: fedora-forgejo:fedoraproject.org, releng:fedoraproject.org, admin:fedoraproject.org, release-schedule-planner:fedora.im, forgejo-chat:matrix.org

Questions

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.

The post F44 Council Elections: Interview with Tomáš Hrčka (humaton, jednorozec) appeared first on Fedora Community Blog.

F44 Council Elections: Interview with Fabio Valentini (decathorpe)

Posted by Fedora Community Blog on 2026-05-29 21:40:43 UTC

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.

The post F44 Council Elections: Interview with Fabio Valentini (decathorpe) appeared first on Fedora Community Blog.

F44 Council Elections: Interview with Aleksandra Fedorova (bookwar)

Posted by Fedora Community Blog on 2026-05-29 21:39:43 UTC

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.

The post F44 Council Elections: Interview with Aleksandra Fedorova (bookwar) appeared first on Fedora Community Blog.

F44 Council Elections: Interview with Hristo Mainov (hricky)

Posted by Fedora Community Blog on 2026-05-29 21:38:35 UTC

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 Hristo Mainov (hricky)

  • FAS ID: hricky
  • Matrix Rooms: #bootc:fedoraproject.org, #coreos:fedoraproject.org, #atomic-desktops:fedoraproject.org, #silverblue:fedoraproject.org, #kinoite:fedoraproject.org, #fedora-forgejo:fedoraproject.org, #docs:fedoraproject.org

Questions

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.

The post F44 Council Elections: Interview with Hristo Mainov (hricky) appeared first on Fedora Community Blog.

© 2016 Red Hat, Inc. and others. Please send any comments or corrections to the websites team.

The Fedora Project is maintained and driven by the community and sponsored by Red Hat. This is a community maintained site. Red Hat is not responsible for content.

Your words are your own, duh. Nothing here represents Fedora™, Red Hat, Inc, or pretty much anything else. If you think it does then you are badly misled