Flock to Fedora 2026

How do you replace the engine of a moving car while simultaneously replacing its paintjob? For over a decade, Fedora Badges has been the cornerstone of gamifying contributions and engaging achievements. However, as we head into 2026, the project faces a double deficit: crippling technical debt on the backend, and a trust problem regarding undeployed modern artwork redesigns.

Our hybrid session dives into the multi year perspective of the Fedora Badges Revamp Project and the artwork design mentoring initiative. In the first half, we will explore the live migration of legacy synchronous systems to a modern application stack, on a staging environment. In the second half, we will find ourselves leveraging the Forgejo Migration to get redesigned artworks online.

This “Design To Deploy Sprint” takes advantage of the recent aggressive move away from Fedora Pagure to Fedora Forge, to finally integrate our lost modern style guidelines into the upcoming Fedora Badges revamp. Thus, emerging from our past coordination disconnects to not just move code and data, but evolve the reward system that unmistakably, establishes the Fedora Project brand.

Questions

• Primary question: How can we simultaneously modernize the legacy Fedora Badges system for the Fedora Forge era while designing modern gamification incentives to revitalize various subprojects and SIGs?
• Engagement question: How do we retroactively honor the modern badge artwork redesigns to restore the trust among the community designers while keeping up with the evolving requirements of the communities?

Relevance

• Experience sharing: Understanding the user personas interacting with the Fedora Badges service platform, their happinesses and their pain points, to find targets to pursue and potentially improve.
• Coordination healing: To openly acknowledgement the disconnection and discover ways to ensure that the efforts do not go unnoticed and time does not go sidelined due to more pressing affairs.
• Tangible progress: To give a milestone update to the community about the engineering progress and design efforts - all while setting the community expectations on the project’s future.
• End-to-end onboarding: To produce a verified batch of production-ready artwork and provide a hands-on experience to the attendees so that they can immediately start contributing to the design.

Methodology

Part 1 - The Engine (Technical walkthrough)

• Identifying the potential risks of continually maintaining legacy systems and finding reasons to modernize the stack
• Recognizing the complexities of the migrating data and evolving service system administration to cloud-native deployments
• Interacting with the staging environment and discussing on balancing technical innovations with community continuity

Part 2 - The Paintjob (Design modernization)

• Reviewing the legacy guidelines against the modern ones and capitalizing on the Forgejo migration for the artwork overhaul
• Collaborating with the attendees to create/refine existing badge artworks using the modern artwork design guidelines
• Uploading the refined badges design artwork to demonstrate the roadmap for the replacing legacy badges artwork process

Interested in audio or video playback? Looking for something to convert you music or videos? Or, maybe you're a video creator? We have something for everyone in Fedora. Come and join us if:

• there's multimedia-related software missing from Fedora and you'd like to get it in
• you've found an issue with multimedia-related software and need assistance in fixing it
• you have questions about audio and video processing and playback in Fedora

We will have some Multimedia SIG members and sponsors present and we'll do our best to help you solve your issues live, help review your package submissions and discuss multimedia-related topics in Fedora.

Fedora’s ecosystem of atomic deliverables (Silverblue, CoreOS, etc) is entering a new era of technical alignment. As we continue our adoption of bootc, we have a unique opportunity to harmonize how we build, deploy, and maintain these variants.

This BoF session is a collaborative space for developers, contributors, and enthusiasts to discuss the roadmap for migrating Fedora Atomic deliverables to a bootc-based workflow. We will dive into the architectural shifts required, the impact on our build infrastructure, and how we can eliminate silos between our various immutable offerings.

Fedora Project is undergoing significant infrastructure changes that affect everyone from distribution users to individual contributors - that is, migrating from Pagure to Forgejo as its primary Git forge for both source code and package sources. Our talk chronicles the journey from the early days of collective debating between GitLab and Forgejo with Fedora Council, through the ongoing migration of thousands of repositories with Fedora Infrastructure.

While the initiative began due to the need to move away from Pagure, it gradually evolved into one that also aimed at fixing the long-standing pain points faced with workflows. We got the opportunity to streamline the processes that made sense about a decade back, and have since then, slowly started getting in the way of contribution. This also allowed us to contribute back to the Forgejo upstream with the features that would end up benefiting all.

This workshop aims to progress along with the work that we have been up to so far with creating solutions for migrating projects from Fedora Pagure and Package Sources. Participants can take advantage of the learnings on building compatibility bridges, CI/CD workflow modernisation, granular permission models, existing toolchain integration and comprehensive documentation writing, while working on building the Fedora Forge platform.

Resources

• Fedora Moves Towards Forgejo - Fedora Magazine https://fedoramagazine.org/fedora-moves-towards-forgejo-a-unified-decision/
• Announcing the Soft Launch of Fedora Forge - Fedora Community Blog https://communityblog.fedoraproject.org/announcing-the-soft-launch-of-fedora-forge/
• Forging Fedora’s Future with Forgejo - Fedora Community Blog https://communityblog.fedoraproject.org/forging-fedoras-future-with-forgejo/
• Git Forge Initiative - Fedora Council - Fedora Wiki https://fedoraproject.org/wiki/Initiatives/Git_Forge_Initiative_2025
• Dist Git Move - Advanced Reconnaissance Crew - Read The Docs https://fedora-arc.readthedocs.io/en/latest/dist-git-move/index.html
• Dist Git Comparison - Advanced Reconnaissance Crew - Read The Docs https://fedora-arc.readthedocs.io/en/latest/dist-git-comparison/index.html

We want to take this opportunity to initiate a lively discussion among Fedora Server Edition users (including future users). This follows on from our survey last year, which yielded a number of suggestions and requests. We would like to start a widespread discussion to coordinate and involve users in further development.

The topics of discussion are open and will primarily be determined by the participants. On behalf of the Working Group, we would like to propose the following topics

• Initialising a participatory software development model to create a homeserver spin-off
• Determine needs for additional documentation to ease the use of features and increase usability
• Measures to elaborate Access protection in addition to user/password method

What does "Secure Development" actually look like in a community-driven ecosystem? With the arrival of the EU Cyber Resilience Act (CRA), the industry is moving toward a more structured approach to software security. This hands-on workshop treats the CRA not as a hurdle, but as a baseline for excellence.

Designed for Fedora maintainers and developers, we’ll start with a practical "Intro to Secure Development," covering the core pillars of writing and maintaining resilient software. It will include an overview of existing security standards and tools specifically designed for open source and that already work.

We will then focus on mapping these practices to the CRA, showing how community projects can stay compliant through good engineering rather than paperwork. We will explore different options where stewards (like Red Hat) are supposed to step up and help, and how to get maximum value out of this collaboration.

We’ll look at the Fedora stack and explore how our existing processes, tools and pipelines can automate security requirements.

Mentorship has always been a big part of what makes Fedora special. After a great response last year, we’re bringing back the Mentor–Mentee Lunch at the Fedora Mentor Summit at Flock 2026, with a small tweak. A casual lunch matching session where everyone can meet face-to-face, share stories, swap ideas, and connect over common goals.

Here’s how it works this year:
* Anyone attending Flock can join.
* Participants are grouped based on topic of interest, no pre-signup required.
* Each day features different topics, so people can explore multiple areas across the event.
* Need a conversation starter? We’ll have a few prompts ready to help break the ice.
* Take a group selfie during lunch and you’ll earn a Fedora Badge as a fun keepsake. 🐧

Topics by day:

Day 1 (Sunday, June 14)
* Documentation
* Operations
* Development
* Marketing

Day 2 (Monday, June 15)
* Packaging
* Infrastructure
* Interpersonal Skills
* Events

Day 3 (Tuesday, June 16)
* Artificial Intelligence
* Governance
* Release Engineering
* Design

No formal structure - just good food and good conversation with someone else who cares about growing the Fedora community.

Have you ever wondered how healthy your SIG actually is? Or wanted to know how to measure the impact of a recent Community Initiative? Data in open source can sometimes feel like a sensitive topic, but when it is built transparently and owned by the community, it becomes a superpower. The Fedora Data Working Group has been exploring new ways to understand our project's health, and we want to share what we've been building with you.

In this workshop, we are opening the doors to Fedora’s analytics ecosystem. This isn't a lecture—it's an open forum and hands-on hacking session designed to demystify how we measure community success.

What we will do together:
* Open Forum & Q&A: Bring your biggest questions about Fedora data. What do you want to know about our community that you currently can't see?
* The Current Landscape: A brief walkthrough of the analytics tools that currently exist within the Fedora community and how you can access them today.
* Exploring Hatlas: We'll introduce the new Hatlas data streams the Data Working Group has been incubating. We want your feedback on how these streams can best serve community needs (including how they might connect to things like Fedora Badges!).
* Hands-On Hacking: We are providing a "Data Bootstrap Kit" for all attendees. We will leave plenty of unstructured time for you to get your local environment set up, plug into the data streams, and start running your own basic queries right in the room.

Whether you are a seasoned data nerd, a Working Group lead looking for better insights, or just curious about how we measure the heartbeat of the Fedora Project, come grab a seat. Let's build a transparent, community-driven data culture together.

Docker Official Images, Red Hat UBI, Project Hummingbird and more all work around packaging rather than with it. Each project maintains custom entrypoint scripts, strips systemd units post-installation, rewrites configs for containers, and removes documentation that RPMs insist on installing.

This doesn't scale. Container concerns should be native to RPM packaging.

This workshop explores what container-native RPM packaging could look like, through the lens of Project Hummingbird—a Fedora-based initiative building minimal, hardened, reproducible container images.

Three provocations:

1. "Why is there no container macro in RPM specs?"
   Should nginx.spec ship both host and container variants? We'll show what this could look like and have attendees design container-native spec files for real packages.

2. "Why don’t packages ship a container entrypoint?"
   Currently, every downstream project (Docker, UBI, Hummingbird) maintains separate entrypoint scripts. Should packages own the canonical container entrypoint? Upstream projects for those entrypoints exist.

3. "Container-native enables better security"
   We'll demonstrate how container-specific packaging enables hermetic builds, locked dependencies, and automated CVE response—features that are harder to achieve when working around traditional RPM assumptions.

This is not just about Hummingbird—it's about the future of Fedora packaging. Should RPM evolve to natively understand containers? Can Fedora lead the ecosystem in solving this problem once, rather than every project solving it independently?

Mozilla community measures 90% of users prefer to use their own language when available.
Linux operating system is likely to have similar user behaviours.

We now have an idea about the current state of localization in open-source community via the processing of 20 years of data (introduced in a dedicated talk)
Numbers are available on https://communityhealth.languages-in-floss.eu

This workshop aims at: understanding the current situation, identifying how to interpret it and identify what could be done by the Open Source community to improve the situation.

Everyone from packaging to translators, developers to ambassadors are welcome, this is subject is focused on how the open-source ecosystem collaborate, which means lot of stakeholders, it is not too technical.

What if all quality checks for Fedora packages happened before merge — at the pull request level? If a PR is approved and merged, the artifact would be ready for users. No separate gating step afterward. Issues caught early, when they're easier to fix.

Could Fedora benefit from such an approach? What would it take to make it work? And what would it mean for our current infrastructure like Bodhi?

This session brings together packagers, infrastructure maintainers, and SIG representatives to explore whether PR-level gating makes sense for Fedora — and to collect the requirements that would need to be met.

We aim to:
- Understand what packagers need from a PR-based workflow
- Identify blockers preventing adoption of PR-only workflows today
- Discuss architectural options and trade-offs

Topics that may come up:
- Multi-package coordinated updates and side-tags
- The lookaside cache
- "Draft builds" and artifact promotion
- The role of Bodhi in a PR-gated world
- ...and whatever you bring to the table

This is not a presentation. We're here to design together. This discussion can ideally lead into a Fedora Change proposal.

Commercial AI assistants are impressive, but they run on distant corporate servers, harvest your data, and can change or disappear at any time. What if you could build your own AI chatbot that runs entirely on your machine, requires no GPU, and is yours to customize however you want?

In this hands-on workshop, you'll build a voice-enabled AI chatbot from scratch using open source tools on Fedora. No expensive hardware required, just a laptop running Fedora with 8GB of RAM.

What we'll build together:
* A local LLM using llama.cpp and a quantized model that runs on CPU
* Speech recognition using whisper.cpp so you can talk to your AI
* Text-to-speech output using espeak so your AI can talk back
* A customizable prompt to give your chatbot personality
* (Time permitting) RAG integration to give your chatbot knowledge from documentation

What you'll leave with:
* A working, talking AI chatbot running on your own hardware
* Understanding of the components that make up an AI assistant
* Ideas and tools to customize and extend your chatbot further

Who this is for:
Anyone comfortable with the Fedora command line who wants to understand how AI chatbots work under the hood, or who values privacy and wants an AI assistant they fully control. No prior AI/ML experience required.

Prerequisites:
* Fedora laptop with 8GB+ RAM and ~10GB free disk space
* Microphone and speakers/headphones

This workshop embraces the DIY spirit. Your chatbot is a starting point, not a finished product. Bring your curiosity and ideas for what you want your AI to do.

The Fedora Docs team would like to invite anyone interested in documentation to come and chat about the future of Fedora docs. We can't promise cookies, but we are interested in your thoughts. Should we merge all docs into a single repo? What's the actual target audience? How do we make sure packagers and testers become more involved? How about sharing docs with CentOS, or even RHEL? Let's discuss!

fbrnch is an helpful and advanced packaging CLI tool for Fedora development.
This is an interactive workshop for Fedora Packagers to learn and understand better how to use fbrnch for package workflows. We will be using fbrnch 1.8.

There will be 3 parts:

1. an overview of fbrnch and its features
2. demos and trying various workflows together
3. Discussion, Q&A, and feedback on the tool

If there is time we can also talk a bit about fbrnch's development and code too

Please install fbrnch-1.8.3 (with dnf) and bring (your) packages, etc to work on!

Location: Hotel Orea Andel's, Oscar's Bar
You will need your conference badge to enter.

It is just like it sounds. At in-person Flock events, Fedora contributors gather to share small pieces of where we come from in our various journeys around the world to get to Flock. At one evening of the conference, we gather people together, spread out several tables, and everyone "contributes" their confectionery item to the table. Typically, we have representation across several countries and multiple continents!

You can add yourself here on the Fedora Wiki: https://fedoraproject.org/wiki/Flock_2026/Candy_Swap

Food & Drink:

• Dinner & Candy: No dinner or food is provided other than the candy that attendees bring to showcase and share. Please eat dinner before arriving and join us afterward.
• Drinks: Complimentary drinks will be provided at the bar.

Join us to officially kick off Flock 2026 with conference organizers.

A brief overview of Fedora in its current state, and a look to the future.

The Fedora Council would like to provide an overview of in-progress draft proposals to the community and hold a live community Q&A session to help refine the proposals further before adoption as project policy.

As during every Flock, we'll hold a session with FESCo members to introduce themselves and say a few words about our plans for the next year. The majority of time will be spent on questions from the audience.

The Hummingbird Project is a set of rapidly rebuilt container images, as small, and with as few CVEs as possible, tracking upstream as closely as possible, enabling users to meet audits and certifications easily.

You might wonder what it has in common with Fedora, how it shares content with Fedora and how it's a contributing part of Fedora. We’ll cover all those topics, and look at the high degree of automation involved, where we use AI, and the build pipelines that we use to achieve this.

But why would we do such a thing? Why would someone want such rapidly updated, minimal containers .We’ll examine that too, and how many users have different expectations of the containers nowadays.

Mentorship has always been a big part of what makes Fedora special. After a great response last year, we’re bringing back the Mentor–Mentee Lunch at the Fedora Mentor Summit at Flock 2026, with a small tweak. A casual lunch matching session where everyone can meet face-to-face, share stories, swap ideas, and connect over common goals.

Here’s how it works this year:
* Anyone attending Flock can join.
* Participants are grouped based on topic of interest, no pre-signup required.
* Each day features different topics, so people can explore multiple areas across the event.
* Need a conversation starter? We’ll have a few prompts ready to help break the ice.
* Take a group selfie during lunch and you’ll earn a Fedora Badge as a fun keepsake. 🐧

Topics by day:

Day 1 (Sunday, June 14)
* Documentation
* Operations
* Development
* Marketing

Day 2 (Monday, June 15)
* Packaging
* Infrastructure
* Interpersonal Skills
* Events

Day 3 (Tuesday, June 16)
* Artificial Intelligence
* Governance
* Release Engineering
* Design

No formal structure - just good food and good conversation with someone else who cares about growing the Fedora community.

As Fedora continues to evolve as a leading open source platform, its documentation quietly acts as critical infrastructure—shaping contributor onboarding, user success, and the long-term sustainability of the project. Yet documentation is often treated as secondary to code, despite being one of the first and most frequent touchpoints for the community.

This talk delivers a practical, experience-driven exploration of documentation within the Fedora Project, examining how docs function as a core system rather than a supporting artifact. Through real-world examples, it highlights how documentation impacts contributor velocity, release quality, and community growth, and why investing in docs is an investment in Fedora itself.

Attendees will walk away with actionable insights on:
• Why documentation should be treated as infrastructure and product, not an afterthought
• Common documentation pain points faced by contributors and users—and how they affect real workflows
• Approaches to improving documentation quality, discoverability, and maintenance without adding heavy process overhead
• Ways to understand documentation effectiveness while respecting Fedora’s commitment to user privacy

Rather than focusing on documentation as a writing exercise, this session reframes it as an essential part of Fedora’s engineering and community ecosystem. Whether you are a contributor, maintainer, mentor, or community organizer, this talk will help you better understand how strong documentation underpins Fedora’s success—and how small, intentional improvements can create outsized impact across the project.

In 2025, the dev work on the new Fedora Forge project has started.

Fedora's new Forge brings built-in workflow automation through Forgejo Actions.
This talk introduces Forgejo runners: what they are, what we can provide, what the limitations are, how to request one for your organization and a little bit about how they are implemented.

Earlier this year, Packit became the default CI system for Fedora dist-git pull requests. This unification replaced the legacy Jenkins-based Fedora CI and Zuul systems with a single service. In this session, we will summarize the technical changes involved in this transition and outline how the system now handles the automated heavy lifting for the packages.

We will explore the current state of the CI and showcase recent improvements, such as integration with Log Detective - an AI-driven tool designed to analyze build logs. In the end, we will cover what maintainers can expect from the project’s future roadmap.

Last year, we conducted a user survey that gave us many insights into the use of Fedora Server Edition. The task now is to incorporate the wishes and requirements into further development.

The data show a high level of satisfaction, particularly with regard to reliability and compatibility, even between different releases. The focus of the next two release cycles will be on improving the user experience, reducing administrative overhead, and enhancing operational security.

There are three areas in particular that are to be addressed

• In response to the high number of home server usages, we will finally create a dedicated home server spin-off. The goal is to combine a high level of environmental friendliness with an easy and comfortable usability similiar to commercial NAS boxes while offering a more powerful configurability. The challenge is to achieve this using standard Fedora tools such as Cockpit and Ansible. We will use Participatory Software Development (PD) methodology to actively involve users in the development process.
• Backup & restore are work-intensive processes, especially for standalone servers without integration into a centralized backup management. And it becomes even more complicated if they are located in a remote data center without even access to a console or USB port. In these cases in particular, it is important to establish an easy-to-use and automated procedure. Using the specific features of the Fedora Server storage concept, LVM and usage-specific logical volumes, should allow for a fast, parallelizable operation. Special attention should be paid to dnf updates, where the backup can be discarded if successful. In the long term, a special dnf plug-in is being pursued.
• Fedora Server in standalone mode currently uses only a simple name/password authentication by default. More elaborate procedures must be installed and configured by the system administrator. It is a complex process and usually not even feasible for standalone servers. The recently available Local Authentication Hub (LocalKDC) provides local Kerberos keys, exclusively locally via Unix domain sockets and executed on demand by socket activation. It significantly expands the functionality for file services such as Samba and can also become bases for the login function of NFS v4. We also aim to remove less secure authentication options such as NTLM.

The European Union's Cyber Resilience Act (CRA) is the first "horizontal" law to formally recognize the role of open source in the commercial software supply chain. While any new regulation at this scale naturally brings questions, the CRA actually offers an opportunity to standardize and elevate security across the entire industry. The law also promotes collaboration between all FOSS ecosystem players - contributors, maintainers, foundations and commercial companies - by introducing the new role of steward. This session is an introduction into what the CRA really means for the community (spoiler - don’t be scared, you’re safe!) and how the true responsible stewards like Red Hat can help..

In the first part, we’re going to strip away the jargon and explain exactly what the CRA is. We’ll cover the basics of the Act: who it applies to, what it asks for, and how it acknowledges the unique nature of open source. We’ll look at the specific exemptions designed to protect the "way we work," making it clear why individual contributors and community-led development remain in a safe, protected space.

The second half of the talk introduces a concept of the Open Source Steward, designed specifically to support community projects. We’ll discuss how Red Hat, as a steward for Fedora, takes on the responsibility for high-level security policies, vulnerability reporting, and coordination with authorities. Join us to learn how this partnership allows the Fedora community to keep innovating freely and preserve its unique culture, style and processes. Red Hat is here to help navigate the new regulatory requirements and improve the project's security posture to keep delivering the best quality Linux distribution to its users.

We often focus on the 'What' (the code) and the 'How' (the tools), but we rarely talk about the 'Who' and the 'Why'. In this personal talk, I want to explore the indispensable human side of Open Source. Beyond SELinux and Podman, there is the art of listening, the commitment to support, and the generosity of sharing experiences.
I will share how 'soft contributions'—like organizing a venue, managing social media, or simply being there to answer a beginner's question—are the true glue of the Fedora Project. This session is a call to action for every contributor to embrace empathy as a technical skill and to realize that sometimes, the most important thing you can 'commit' is your time and mentorship.

After a three-year hiatus from the global stage, Fedora Mexico has undergone a significant transformation. In this session, we will share the journey of how we revitalized one of the most active Spanish-speaking communities in the project.
We will dive into the specific strategies that led to our recent progress: from establishing a core administrative team and fostering group harmony to organizing high-impact local events and release parties that bridged the gap between beginners and expert users.

Attendees will learn:
- The 'Mexico Model': How we localized the 'Four Foundations' to resonate with the local tech ecosystem.
- Scaling Engagement: Practical steps for onboarding new contributors and maintaining momentum in a regional chapter.
- Revitalization Tactics: How to recover and grow a community after periods of inactivity.
This talk is not just a success story; it is a technical and human blueprint for any contributor looking to strengthen their local presence and align it with the global Fedora Strategy. We want to show how 'Friends' and 'Freedom' work together to build a lasting legacy in Latin America.

Audio and video processing libraries are a critical part of Fedora now. Several Fedora contributors have been working to give Fedora users the best possible multimedia experience out of the box and our efforts accelerated in 2022. Are we there yet? Join this talk to find out the current state of multimedia software in Fedora, the challenges we're facing and what we (and you!) can do about them.

Large Language Models require frequent updates as training progresses, but
traditional file-based deployments create downtime and risk incomplete
transfers. This talk demonstrates how Fedora Cloud Edition's native BTRFS
support enables atomic model updates through subvolumes and incremental
transfers.

We'll explore a production architecture where LLM training occurs on dedicated
servers, creating BTRFS snapshots of updated models. Using btrfs-send, only
changed blocks transfer to Fedora Cloud instances running inference workloads.
The receiving system performs atomic switchovers between model versions via
subvolume mounts, enabling instant rollbacks and zero-downtime updates.

The shadow project has recently adopted a new system test framework built on Python, pytest, and pytest-mh. This modern approach allows us to perform robust end-to-end (E2E) testing of core utilities, such as useradd, usermod, and passwd, across multiple distributions including Fedora, Alpine Debian and openSUSE. However, the true value for our ecosystem lies in running these tests within the Fedora infrastructure to catch regressions before they land in the distribution.

This talk focuses on the practical experience of enabling these upstream system tests in Fedora CI. I will walk through the technical process of using the Test Management Tool (TMT) and Testing Farm to bridge the gap between upstream development and Fedora packaging.

In this session, you will learn:
* The framework architecture: how we use pytest-mh to create a high-level API for system interactions and ensure a clean environment after every test run.
* Fedora CI integration: a deep dive into the TMT configuration required to trigger upstream Python tests during the Fedora build and gating process.
* Local vs. remote execution: how to run the exact same test suite effortlessly on a local machine and in a cloud-based CI environment.
* Lessons learned: insights into handling "destructive" system-level tests in CI, managing artifacts for easier diagnostics, and the benefits of a distribution-agnostic test suite.

I will demonstrate the framework in action with practical examples, showing how this integration improves the reliability of one of Fedora's most critical core packages.

In open-source projects, designers with technical backgrounds bring a unique perspective that bridges the gap between creative vision and practical implementation. This talk explores how understanding code, development workflows, and technical constraints can elevate design work in open-source environments, leading to smoother collaboration, more feasible designs, and faster iteration.

Drawing from my own journey from engineering to design, I’ll share practical techniques for creating developer-friendly design assets, communicating effectively with technical contributors, and using interactive prototypes to resolve UX issues early. I’ll also discuss methods for gathering and interpreting community feedback and offer tips on mentoring designers within open-source communities, helping them embrace a developer-centric approach.

Attendees will walk away with actionable insights on integrating technical know-how into their design process, empowering them to create high-impact, accessible, and cohesive designs that enhance open-source projects for all.

A successful build is only the beginning of an artifact’s journey to a user’s device. Before it can be shipped, it needs to be digitally signed so that users can be certain it’s been built by Fedora. In this talk, we'll cover how signing works in Fedora, and why it's time to upgrade our infrastructure.

The talk will begin with an introduction to the content we have historically signed, content we’d like to sign in the future, and why.

We will then examine Sigul, the signing service Fedora has used for many years. The service design will be covered, and how it works within Fedora’s infrastructure to sign various build artifacts. We’ll step through the flow for a few common artifact types like RPMs and UEFI applications.

The next portion of the talk will cover Siguldry, a new signing service that is heavily inspired by Sigul. The architecture will be compared with Sigul and differences will be highlighted and explained. We’ll also go over what new features people can expect, including support for RPM v6 signature features, post-quantum cryptography, signatures for use with Cosign, and more.

Attendees should come away from the talk with a good understanding of the signing process, the projects involved, and how to contribute to it to ensure it remains in good working order.

When someone talks about a Linux distribution's infrastructure, often it is about packaging and producing the resulting bits that end users install on their systems. However, there is more to that: an infrastructure also includes a wide variety of components, including trusted user information and authentication to the project's services.

In this talk we will look into the state of both the packaging infrastructure and Identity management infrastructure of Fedora and CentOS Stream in their preparedness to transition to use of post quantum cryptography.

The Packaging and Testing Experience (PTE) group brings together tools you likely already use: Copr, Testing Farm, tmt, Packit, and Log Detective. Our mission? Bridge the gap between upstream development and Fedora packaging—making the whole pipeline smoother.

A lot has been happening across these projects, and we want to share what's new and what's coming.

There's something for RISC-V enthusiasts. Multihost testing fans will find new capabilities in Testing Farm. If you've ever stared at a failed build log wondering what went wrong, Log Detective is getting smarter at helping you out. The tmt team is rethinking how test artifacts are handled. And Packit continues to expand what's possible with automated packaging workflows.

We won't spoil all the details here—come to the talk to see what we've been working on.

And if you have opinions about these tools—good, bad, or "why doesn't it do X?"—we want to hear them. Your feedback shapes where we go next.

You’ve volunteered to represent Fedora at a massive event. You’re ready to talk kernels and containers, but then reality hits: The projector is flickering like a strobe light, the booth power has mysteriously vanished, and you’re pretty sure you’ve contracted the legendary "FOSDEM Flu." Organizing Fedora’s presence at giants like SCaLE (the largest community-led OSS conference in North America) and FOSDEM is a high-wire act. It’s easy to focus on the swag, but the "invisible" administrative work is what keeps the wheels from falling off. If you've ever asked yourself, "Where is my room?" or "How can I print these 5000 stickers for tomorrow?" this session is for you.

Drawing on years of experience (and a few gray hairs) from owning and co-owning Fedora’s presence at these massive gatherings, we'll be digging into:

• The Paperwork Jungle: Navigating Mindshare, budgets, event pages, and the dark art of timely reimbursement reports.
• Logistical Disaster Management: What to do when the power goes out, the swag is stuck in customs, or the hotel where your room block is tells you that your reservation is cancelled.
• The Human Element: Managing volunteer burnout, engaging 10,000+ attendees without losing your voice, and surviving the post-event exhaustion.

This isn’t just a lecture; it’s an invitation to build a collaborative guide for all Fedora Ambassadors. Let’s learn from the nightmares of the past to ensure our future events are smoother, more professional, and most importantly,fun.

Fedora bootc introduces an image-based approach to building and operating Fedora systems, using OCI container images as the unit of delivery for the OS. Instead of managing drift through post-install configuration, bootc treats the image itself as the source of truth, while still allowing controlled, intentional changes at runtime. We'll demonstrate how bootc's container-native approach makes it easy to test OS images in CI using standard container tooling(BCVK) before deploying them to production.

This talk provides a practical introduction to bootc for Fedora contributors who are new to image mode, followed by a deeper look at how Fedora bootc fits into Fedora’s growing set of image-based operating systems. We’ll discuss how bootc systems are built, updated, and operated, and where they intentionally differ from traditional package-managed hosts.

We’ll also explore how Fedora bootc builds on lessons from Fedora CoreOS and other image-based efforts in Fedora, highlighting shared concepts, differences in design goals, and areas of convergence. Throughout the session, the focus is on real-world use cases, trade offs, and lessons learned from working on bootc as part of the image mode team.

Attendees will leave with a solid understanding of what bootc enables, when it is a good fit, and how it fits into Fedora’s broader direction.

Location: Manifesto, Culture Zone
Ostrovského 34 15000 Prague

Join us for the official conference reception! Entry is open to all attendees on a first-come, first-served basis. You will need your conference badge to enter.

Please use dedicated entrance for Flock guests. There will be signage once you enter the venue.

Food & Drink:

• Mains: You will receive food vouchers to choose your main dish from over 10 marketplace restaurants.
• Appetizers & Dessert: Enjoy appetizers and grab a surprise dessert in our area.
• Drinks: Order directly from the onsite bars.

More than 6 years back, the Fedora translators community found their new home with Weblate. The migration from Zanata was a complex task that was performed beautifully by several community members, and it kicked off a success story. Many smaller, Fedora-related projects joined Fedora's Weblate instance and created a place where quality translations provide a reliable base for the happiness of the users, developers, and translators alike. Everybody benefits from good translations, and a good setup makes the work nearly effortless. I will show some numbers to spotlight this success and compare it with similar projects. And how easy it is to join this party for any maintainer.

The wheel of time turns and draws us ever nearer to a new Red Hat Enterprise Linux major release. Over the next year, there will be a flurry of activity aimed at readying things in Fedora for branching to Red Hat Enterprise Linux 11. We will give you an overview of what kind of things packagers and contributors can expect to see happening and what requests might be made of you as we approach this milestone.

Your package update has failed openQA tests, and you are looking at the results page. Screenshots, logs, test names ... where do you even start? The behaviour looks weird, but you are not sure if it is your package's fault or something else entirely. This is a common scenario that leaves many packagers confused and unsure how to proceed.

This practical, hands-on talk will guide you through navigating openQA test results from a packager's perspective. We will start at the results page and walk through exactly what to look at and where to find it. You will learn how to identify whether a failure is likely caused by your package or if it is an infrastructure issue. We will explore where the logs are located, how to understand what exactly was tested, and how to use the test video to diagnose problems.

By the end of this session, you will have the knowledge and confidence to investigate openQA failures on your own and make informed decisions about how to proceed, whether it is fixing your package, requesting a retest, or asking the QA team for help.

Linux operating system provides translations for many languages, good, it works!
But how many written languages does exist in the world? How do it compare to what Fedora Workstation provides? How healthy are the communities providing translations for these languages?
Fedora mirrors were used to process the last 20 years of software deliveries and help to to understand this.

A lot has changed in how the Fedora kernel is maintained. This presentation will cover our current environment. It will explain how to easily build a test kernel to validate patches from upstream. And go into a bit of detail on why we are maintained in such a way.

Porting Fedora to RISC-V began in 2016, long before physical hardware was accessible to developers. Today, the vast majority of Fedora packages have already been ported to riscv64 (i.e. the RV64GC baseline). OS images—both generic and board-specific—are available for recent releases. RISC-V is currently an alternative architecture in Fedora, so these (non-official) images are built by a team of community contributors, the Fedora RISC-V SIG. The end goal is to make RISC-V a primary architecture on Fedora.

So, what changed since the past updates at FOSDEM[1] and DevConf[2]? What does the path for RISC-V to become a primary architecture on Fedora look like? Where are we currently working on and what are the plans for future?

Beyond software, we'll also briefly survey the current hardware reality. If one is getting started with RISC-V today, what board to pick? We'll review the available hardware, from the "VisionFive 2" to other capable boards, and outline our experience building Fedora on it. Finally, whether you have a board on your desk or just a desire to contribute, there are many ways to make a meaningful contribution. Join us to learn more.

[1] FOSDEM 2026, Fedora on RISC-V: https://fosdem.org/2026/schedule/event/SQGLW7-fedora-on-riscv/
[2] DevConf 2024, An update on Fedora’s RISC-V port: https://pretalx.com/devconf-cz-2024/talk/Q7XB3M/

Documentation has been a weak point of Fedora for years now. The misery has reached a level that makes our distribution difficult to use. The more sophisticated and technically elaborate our distribution gets, the greater this problem becomes. Ultimately, our efforts at technical innovation and elegance are wasted. Our efforts are ultimately destined for the to be thrown away, or at best, to be used by a small circle of contributors themselves and a dedicated fan base, instead of being a "Digital Public Good" meant for anyone to use. We are endangering ourselves with this situation.

Our Fedora Docs initiative, which we have started last year, aims to put a sustainable end to this unfortunate situation.

After some preparatory work, we now come to the core. The two essential parts are:

• Cleaning up the fragmentation of our work base by migrating anything to our new forge (forgejo), and
• Overcoming the communication gap between our technical hemisphere and our user and utilization (via documentation teams) hemisphere.

At this talk, we will present proposal and measures, and discuss ways to participade in documenting Fedora

scrapers have been affecting our internet more and more, and the fedoraproject is no exception.
In this talk, I'll go over:
* What this has looked like to us and how we have tried to mitigate things
* Some things that have been proposed to help solve the problem
* a discussion about what we can/should do and how open source communities operate in a hostile scraper universe.

Fedora Linux was my primary development environment for day-to-day engineering work. This talk presents a practical, experience-driven field report on using Fedora as a full-time developer workstation, focusing on how it performs under real production workloads rather than idealized benchmarks.

The session offers an in-depth look at Fedora’s developer experience across an extended period of active development. From frequent system updates and evolving toolchains to container workflows and frontend/backend development stacks, this talk explores how Fedora behaves when it is not just tested—but relied upon.

Attendees will gain actionable insights on:
• How Fedora Linux 45/46 performs as a daily-driver OS for professional development over several months
• The impact of rapid updates on developer productivity, system stability, and workflow continuity
• Real-world experiences with containers, developer tooling, browsers, and the JavaScript/Node ecosystem on Fedora
• Where Fedora excels as a developer platform—and where improvements could meaningfully enhance future releases

Rather than promoting Fedora uncritically, this talk shares honest lessons learned from real usage, highlighting trade-offs, unexpected challenges, and practical solutions. Whether you are a Fedora contributor, mentor, or developer evaluating Fedora as a workstation OS, this session provides grounded insights to help shape better tooling, onboarding, and future Fedora releases.

Fedora Test Days provide a structured, collaborative environment where contributors and users can test new versions before they are released. Accessibility (a11y) should be a key attribute of each modern SW Project. That is why there has been a separate set of tests for accessibility as part of test days since 2024. Now this set was expanded to cover even wider functionality in the area of desktop accessibility for users.

The talk will explain how a11y testing is conducted during Fedora Test Days. We will also highlight workflows, tools, and best practices used to identify accessibility regressions and usability barriers. The role of assistive technologies, real-world user testing, and collaboration between developers, QA contributors, and users with disabilities is also important.

Our goal is to encourage broader participation in accessibility testing during Fedora Test Days. We hope this will help Fedora to deliver an inclusive, accessible open-source operating system.

Compliance doesn't have to mean installing a black-box proprietary agent. For organisations running Fedora, "Freedom" means the ability to audit your own security tools. But as the Enterprise Linux world shifts toward immutable, image-based systems Silverblue, Kinoite, and RHEL's bootc. the rules are changing.

This session bridges the gap between today's compliance requirements and tomorrow's atomic desktops. We'll start by demonstrating how Fleet translates NIST controls into transparent SQL queries on traditional Fedora workstations. Then we'll explore what breaks when the filesystem goes read-only, and how to adapt.

We will cover:
Compliance as Code: Mapping NIST 800-53/171 controls to osquery policies
The Immutable Challenge: Why traditional remediation fails on atomic systems
Querying the Image: Inspecting rpm-ostree status, verifying boot digests, and detecting drift
Practical Patterns: Real-world deployment considerations (like where Fleet's writable state actually lives)

Join us to see how open-source observability is evolving alongside the Cloud Native Desktop.

Package maintainers for Linux distributions often assume that users keep up with their operating system's support phases. We know that this is not always the case and users are often surprised by end of support events or find themselves accidentally running software past its end of support.

Amazon Linux is AWS homegrown Linux distribution based on Fedora. This session will present how Amazon Linux addresses this visibility gap with the addition of the supportinfo.xml file in its rpm repositories. Supportinfo is a vendor-agnostic file format to document package lifecycle and support levels. It can be used by the package manager (e.g. dnf) and 3rd party applications (e.g. security scanners) to notify users of packages' end-of-support event for installed packages and/or the distributions as a whole.

Two years ago, Microsoft established the Community Linux Engineering team. Last year at Flock, we shared our first year of work with Fedora. This session covers what we delivered in year two, our plans for the year ahead, and why we continue to invest in Fedora.

First, we'll look back at the past year and highlight work we shipped. We automated Fedora Cloud image testing on Azure using LISA (Linux Integration Services Automation), Microsoft's open source testing framework for validating Linux distributions across Azure, HyperV, and other platforms. The signing infrastructure work mentioned at Flock 2025 is nearing completion, with a separate talk submitted on that topic. Various improvements to the WSL image were delivered in Fedora 43. We remain active contributors to the Fedora Cloud SIG and continue to help “keep the lights on” with maintenance work on packages like cloud-init.

We'll share consumption data for Fedora in the Azure Community Gallery, where Fedora was a launch partner in 2024, and present usage trends for Fedora on WSL.

Next, we'll discuss work planned for the year ahead, building on the testing and infrastructure foundations we've built. Of particular interest to the team is enabling post-quantum signatures for RPMs and other artifacts, investigating Unified Kernel Images (UKIs) for, among other things, the Azure cloud images, and ensuring those UKIs contain PCR signatures.

Finally, we'll wrap up by talking about why Microsoft commits resources to the Fedora Project and what we hope to accomplish through this effort.

If you messed around with Python's command line options or read the official documentation, you might wonder what the -Xgil option or the PYTHON_GIL environment variable did to your scripts, and whether setting either affects performance. The hubbub on popular wheels such as pyo3, python-zstandard, numpy, uv, cffi, and cython supporting the free-threaded interpreter is no passing fad either. For Pythonistas that don't read PEPs in their spare time or contribute to the cpython project itself, an adventure that delves into a less known, yet jaw-dropping aspect of Python awaits!

Python's Global Interpreter Lock, which determines which single thread can execute native Python code and call C API functions, simplifies writing multithreaded code. However, sticking with this execution model leaves out extra performance afforded by modern multicore CPUs with hyperthreading, as automatic locking and unlocking of the GIL does not scale well with thread counts, especially in performance-sensitive workloads.

The newfangled free-threaded interpreter promises salvation when running either pure Python code or with compiled extensions. General multithreading rules apply (prefer thread-local variables, using locks to prevent simultaneous access of shared data), but when dealing with projects containing compiled extensions that directly or indirectly interface with Python's C API, more porting rules also apply.

Key porting tips, including projects using the Limited API, include: port native code away from C API functions that avoid borrowed references because they aren't thread-safe; modify unit tests to catch concurrency bugs arising from assuming the presence of the GIL; and extend CI coverage of Python interpreters both for testing and to build free-threaded compatible wheels.

In the last year, I've spearheaded the work on the migration of our very old Nagios system to a new Zabbix setup. If you're in #noc on Matrix, you've probably noticed this already ;)

In this talk, I'll go over:
- Why we wanted to replace Nagios
- Why we think Zabbix is a good fit
- What Zabbix looks like & how you use it
- The way we're structuring the Ansible code (yes, that means monitoring tasks in your role)

It'll be a high-level review of where we're at, with some next steps for those that want to get more hands-on with Zabbix. If you interact with Fedora Infra, and want to understand how to watch or contribute to it, this talk is for you.

In this talk we will highlight the changes in fedora coreOS we achieved last year, and what the roadmap looks like for the year ahead.
We will also address the challenges we hit and those we forsee.

Non-exhaustive list :
- migrating to OCI distribution
- Container native build
- Bootc integration progress
- Integration with konflux
- Migrating to bootc-image-builder
- systemd system-extensions persperctives

Our presentation will discuss why it’s so important to use non-proprietary design software in general, in Fedora, and the numerous benefits it offers. Attendees will learn:
- Just like code, your design work is not created in a vacuum. You’re making an asset to be reused and reworked.
- Everyone has a different financial background - these are accessible to everyone.
- Professionals can and do use FOSS - the work doesn't suffer.
It’s easier than you think to use these programs! Anyone can use them!

Mentorship has always been a big part of what makes Fedora special. After a great response last year, we’re bringing back the Mentor–Mentee Lunch at the Fedora Mentor Summit at Flock 2026, with a small tweak. A casual lunch matching session where everyone can meet face-to-face, share stories, swap ideas, and connect over common goals.

Here’s how it works this year:
* Anyone attending Flock can join.
* Participants are grouped based on topic of interest, no pre-signup required.
* Each day features different topics, so people can explore multiple areas across the event.
* Need a conversation starter? We’ll have a few prompts ready to help break the ice.
* Take a group selfie during lunch and you’ll earn a Fedora Badge as a fun keepsake. 🐧

Topics by day:

Day 1 (Sunday, June 14)
* Documentation
* Operations
* Development
* Marketing

Day 2 (Monday, June 15)
* Packaging
* Infrastructure
* Interpersonal Skills
* Events

Day 3 (Tuesday, June 16)
* Artificial Intelligence
* Governance
* Release Engineering
* Design

No formal structure - just good food and good conversation with someone else who cares about growing the Fedora community.

Come on stage and give a 5-minute presentation about any topic you want! Slides optional.

From getting resources for swagpacks to laying foundations for conferences, the Fedora Mindshare Townhall Session creates an inclusive and structured space for attendees to meet with their representatives, discuss community health, talk engagement strategies, and identify recognition opportunities and evaluate regional growth. This session will briefly cover what the committee has been up to since the last Flock To Fedora conference, before opening up the space for curious questions and open conversations.

While focusing on surfacing challenges and exploring opportunities related to contributor experience, crossteam collaboration, event impacts and outreach effectiveness, participants will be encouraged to share perspectives from their home regions, propose improvements to the committee's processes, and identify concrete next steps that can strengthen the Fedora Project's global community over the next release cycles. Hence, this session intends to take full advantage of both the participants and attendees present at the event.

Fedora is built by contributors working across many areas such as development, documentation, design, QA, infrastructure, user support, mentoring, and outreach, many of which happen behind the scenes. The Fedora Contributor Recognition Program was created to recognize and reward outstanding contributions to the Fedora community. In this session, we will explain how the program works, from the open nomination process to the review and selection process carried out by experienced Fedora contributors using criteria such as impact, quality, innovation, and community engagement. We will also share lessons learned from running the program last year. The session will conclude with the announcement of this year’s winners, celebrating their work and highlighting the many ways people contribute to Fedora.