20 Aug 2026 8:00pm GMT

If you've ever tried to make something work better by adding or changing a process, you may have noticed that the something got worse. Whether that worseness surprised your or not depends on if you've heard of the "J curve" concept. A J curve is any graph that looks like the letter "J": a sharp dip followed by a sharp rise.

The J curve in open source projects

The phenomenon appears in many fields - economics, medicine, and technology. Where might you see it in your project? Maybe you add automated tests to reduce the manual QA work you do pre-release. This should allow you to ship your releases faster. Except once you introduce it, you spend twice as much time fixing bugs because you find so many more. The next release ships slower. But once you've caught up, the benefits you expected appear. Bugs - particularly regressions - get caught (and therefore fixed) faster.

Similarly, you might start blocking changes that include vulnerable dependencies. This should improve security for your users. But the first time, every dependency is full of vulnerabilities. This, at least, makes the apparent security worse. And maybe the actual security as you take time to prioritize and fix vulnerabilities in dependencies that would have been "accidentally" fixed in routine updates anyway. Again, after you have a handle on the situation, the process works as intended.

Progressing through the curve

Recognizing where you are in the curve is important to navigating it. Are you still on the downslope? Have you leveled off? Are you on the way up? If what you're trying to change is measurable, then tracking those measurements will help. Of course, not everything is easily or meaningfully measurable. In those case, you can trust your intuition. Do things feel like they're still getting worse? Better?

The main thing is to make everyone aware of the J-ness before it starts. Acknowledge that things will get worse for a little bit and then you'll see the improvements. Avoiding surprise is the key to keeping people engaged, and keeping people engaged is the key to seeing the change through and not ending permanently in the "worse" state. Unfortunately, it's hard to answer the "how much longer will it take?" question; there's no magical way to know how long the curve is. Which leads us to…

Limits of the J curve

The J curve is a useful concept, but it's not an inviolable law of physics. While there are plenty of reasonable explanations for why the J curve phenomenon occurs, there's no guarantee that it will. Just because you think it will, does not mean it will. Sometimes, our ideas for making things better don't work.

As I said above, you can't predict where you'll go next - even if you've been meticulously tracking the thing you care about. This, combined with the "it might not get better" aspect, means you could be on an endless march into darkness. At some point, you have to decide it's time to bail out.

So what do you look for if you can't predict the future? Let's go to calculus class for a moment and think about the second derivative. In other words: the rate of change of the rate of change. If you're really on a J curve and not a ramp into hell, the second derivative should become positive pretty quickly. ("Pretty quickly" is relative to the scope and impact of the change.) Even if things are still getting worse, you should see them getting worse more slowly. As long as the second derivative stays positive, you're on a good track.

Finally, and what I've often seen ignored, is the fact that the upward part of the J doesn't continue forever. At some point, you've maximized the gains you can see from that change. That's fine. Contrary to investor beliefs, things do need to level off at some point. The Satir Change Model, developed by family therapist Virginia Satir, is a good representation of a realistic J curve, complete with a new equilibrium state at the end.

This post's featured photo by Zyanya BMO on Unsplash.

The post The J curve, or: it gets worse before it gets better appeared first on Duck Alignment Academy.

19 Aug 2026 12:00pm GMT

Earlier this month, I published a post about the future of Boxes where I detailed the huge technical rewrite I have been doing, porting to GTK4, Libadwaita, and replacing our SPICE display widget with Libmks. Today, I want to share a structural decision that aligns with that vision and sets up the project for long-term health/sustainability.

I have formally submitted a proposal to remove Boxes from the core-developer-tools set in gnome-build-meta and transition it towards becoming an independent application (with the ultimate goal of applying for GNOME Circle once all criteria are met).

I want to dive into why I am making this move, what it means for users and maintainers, and why I believe this is the right path forward.

There is No Drama Here

First off, let's get this out of the way: there is zero drama between Boxes and the GNOME project.

Boxes continues to be built by the same core set of contributors, fully committed to the GNOME Human Interface Guidelines (HIG) and deeply integrated into our ecosystem. We aren't stepping away from GNOME. We are simply right-sizing how Boxes is categorized, distributed, and maintained.

Why Boxes Shouldn't Be "Core" (and Why Versioning with the OS is Outdated)

The desktop Linux landscape is shifting toward image-based operating systems with atomic updates and immutability. In this model, the underlying operating system provides a slim, reliable base, while applications live on top and update independently at their own pace.

Tying a complex application like Boxes to the biannual GNOME release schedule is not useful anymore. It forces us to hold back features and bug fixes for months just to align with the OS cadence, when users should simply get updates when they are ready and stable.

Furthermore, virtualization isn't an essential utility that needs to be pre-installed on every single user's machine by default. Boxes fits much better as a targeted application users explicitly choose to install when they need it.

Flathub-First: Moving Fast and Ending Distribution Bottlenecks

As a maintainer, maintaining separate code paths and stable branches for dozens of traditional distribution packages is simply not sustainable long-term. I can no longer afford to maintain multiple stable branches. Moving forward, I am simplifying maintenance down to one stable branch and one development/nightly branch. To make this sustainable, Flathub is our primary and only officially supported distribution method.

By bundling the virtualization stack in our Flatpak, we ensure that users get a much more tested, consistent, and working virtualization backend regardless of what operating system they are running.

Moving out of Core allows us to heavily discourage downstreams from individually packaging Boxes. Instead, distros should defer their users to the official Flatpak on Flathub. If you are filing bug reports or seeking support, the Flathub build will be the baseline.

Branding and Infrastructure Changes

To reflect this independent status, a few logistical changes are happening alongside this move. We are dropping "GNOME" from the user-facing app branding. Going forward, it will simply be named "Boxes", and we will soon be moving to a new website domain (which is currently being finalized). Importantly, our Flatpak application ID will remain org.gnome.Boxes for full continuity and compatibility. This means existing installations, user settings, and Flatpak configurations won't break, and users won't need to reinstall anything.

What's Next?

This change gives us the flexibility to release updates whenever features are ready, iterate faster, and dramatically reduce maintainer burnout, all while delivering a more reliable and consistent user experience via Flathub. Once we settle into this new cadence and finalize our transition, we plan to apply for GNOME Circle.

To set clear expectations on timing: since Boxes currently uses GTK3 in its stable releases, we will soon submit an application for GNOME Circle review following our GTK4/Libadwaita rewrite.

If the Circle application is approved before the GNOME 52 Alpha deadline, the plan is to proceed with the removal from core-developer-tools and transition to Circle in time for the GNOME 52 release in March 2027.

For distribution maintainers wondering about upcoming distro releases: distros targeting GNOME 51 can continue to package the GNOME 50 release of Boxes, which will remain supported for the standard lifecycle of that release. If everything goes according to plan, GNOME 52 won't include Boxes in the core set anymore. At this point, please don't package Boxes anymore.

19 Aug 2026 10:12am GMT

After years of technical research and foundational work, the Fedora Badges application service has been rebuilt from the ground up, and it is heading to production. Whether you have been collecting badges for years or you are brand new to the Fedora Project community, here is what is waiting for you there.

Completely modernized user interface

The archaic server rendered pages are now gone. The Fedora Badges application service now runs on a modern single page application. This provides you with a much faster and more responsive experience, while functioning across various screen sizes and devices types, all without full refreshes or front-end reloads.

Navigations have been revamped as well. But do not worry at all - if you have bookmarked any old service links, they should redirect you to the right place.

Colour schemes, Dark mode

You can now customize the look of the Fedora Badges application service choosing from eight colour schemes. Your choice flows through the various elements of the front-end - from navbar to borders, from charts to accents, etc. The dark mode and light mode switch respects your system preference and can also be toggled.

Your choices are persistent across visits residing in your session storage. As long as the same session is used, the colour schemes and dark mode settings stay.

Revitalized badges collectathon experience

Not only does the profile page show your precious badges, it also shows a radar chart that maps your collection across categories. This is a rudimentary method to gauge your progress and discover the areas you have not explored yet. Giving a means to diversify the activities, this encourages more people to join in.

The refreshed history page also adds a collection time-line chart showing yours (and your friends') contribution activities over months and years at a glance.

Compare (or compete) with your friends

The renewed difference page lets you compare your badges collection with those of your friends' possessions. See which badges you both share, which ones only you have, and most importantly, which ones they have earned that you have not yet. It's a fun way to discover new badges and unearth new ways to contribute.

You can also reach out to your fellow community members for potential mentoring opportunities, based on their contribution activities and collected badges.

Explore badges by rarities

Every active badge now has a rarity tier based on how many users currently hold it:

• Fedorable - Unobtanium stuff
• Legendary - Mythical prestige
• Epic - Serious bragging
• Rare - Principled hustle
• Uncommon - Striving future
• Common - Warm greeting

You can now browse active badges by their rarity tiers, making it easy to hunt down the ones that fewer people have earned. Not only does it allow you to find new pathways for contribution, you also get a sense of the impactful work and relevant tracks that are waiting for you in your community activities.

Involved semantic collective lookup

Departing from different searches for badges and users, the search bar now helps unified lookup across both badges and users. Start typing and results start appearing immediately after - with better lookup results. These will appear when the query is general enough to return more than eight results.

To save server resources, the asynchronous search request begins only when at least four characters are entered into the search bar for the query.

Leaderboards with time navigation

Departing from the restricted rankings page, it is now possible to request custom period filtering on the leaderboards page. Filters can be based on days, weeks, months, and years. One can see who has been earning most badges in those times, and generally look back at the community's evolving progress over a time period.

The rankings are deterministic and can be shared with others, using the sharing link that inherently applies the same filters. This creates a reproducible resource.

Clearer badge activity lifecycle

Badges can now be manually marked as legacy (retired, unobtainable) after they should no longer be awarded to the users. For instance, the badges for joining the Fedora Linux Release Party 42 should no longer be available to new users in 2026. Hence, they should not be accounted for while computing rarity tiers.

And nope - we are not taking awarded badges away from users who have already earned them. These retired badges are still going to be visible in the history.

Stronger foundational supports underneath

You see, the revamp was not just about the front-end. The data layer that powers the application service got a major overhaul as well. The Database Library project, which handles all database operations, saw 105 commits across 7 contributors during the same period, pushing from version 1.4.1 to 1.5.5.

Here's what changed under the hood, and why it matters to you:

• Faster queries - Redundant database lookups were eliminated, foreign key indexes were added, and pagination now happens at the database level instead of in the application code. Pages that list badges or users load significantly faster, especially as the count of badges or users grow.
• Effective lookup - The search you use from the navbar section is powered by new search methods added to the API. This covers both badges and users. This not only makes the search noticeably faster, but the actual process is also more efficient on a synchronous database accessing layer.
• Rarity calculation - The rarity tiers you see on badge pages are computed every day by an updated algorithm in the API code. Various edge cases are now handled too. The fall-back is set to the common tier on zero available users who own the said badges at that particular time.
• Legacy support - A schema level change was made to introduce a new
  legacy
  column to the
  badges
  table to distinguish active badges from the retired ones. Filtering is built into the API code so the front-end shows them on separate pages when requested by the users.
• Categories normalization - Badge tags are now stored in their own tables instead of as raw comma separated strings. This makes category browsing reliable.
• Cascading deletions - Removing a badge when done in exigent circumstances now properly cleans up its assertions in the database purging orphaned data.
• Removing invitations - Invitations are soft deleted and not hard removed. This preserves access history while preventing accidental assertions.
• Quality assurance - Nearly every new feature ships with its test cases. Python < 3.9 support was dropped in favor of Python > 3.13.

Overall smoother authentication events

Authentication has been reworked. The old session-based login has been replaced completely with a modern token-based flow using OpenID Connect. The application service now has its own dedicated authentication client so logging in through Fedora Accounts is more consistent across other things.

If you are visiting for the first time, like it has been for years, your user account is automatically created without requiring any further steps.

Your privacy really matters

Email addresses are no longer visible across various API responses. They are hashed before being sent as an asynchronous response, for use by Libravatar. Users have the choice to opt out of the Fedora Badges application service entirely. In that case they will stop receiving badge awards for their community tasks.

RSS feeds are now limited to recent entries for performance and efficiency, so you can still stay informed about the latest incoming activities on the app.

For badge creators, maintainers, and administrators

If you are a part of the team, the new interface gives you a full set of tools.

• Advanced database management front-end
• Creating and revoking awards from your users
• Creating and expiring invitations for the badges
• Creating and revoking authorizations from your users
• Creating and updating badges
• Creating and updating users

Access control is tiered - community members see the service experience, while authorized team members get the administrative controls they need.

Progress by the numbers

This revamp (codenamed स्वातंत्र्य or Svātantrya) represents a year of active work across the two repositories. These comprised 165 commits in Tahrir and 105 commits in Tahrir API. This occurred after many years of technical research and foundational work resulting in a leaner codebase with a net reduction of 13,320 lines of code.

Thank you to our amazing contributors

I mean it when I say, this revamp would have been dead in the water without the help of the following folks (in the alphabetical order):

• Akashdeep Dhar
• Aurelien Bompard
• Awwal Adetomiwa
• Chibuezem Marvinrose
• Daniel Mungai Chege
• Emma Kidney
• Gregory Sutcliffe
• John Iweh
• Joy Aruku
• Kevin Fenzi
• Michael Scherer
• Michal Konecny
• Olamide Peter Ojo
• Payal Sumbhe
• Shounak Dey
• Vanshikha Shri
• Yash Sheorey
• Xavier Lamien

And those, of course, from Flock 2026's workshop on the Fedora Badges Revamp Project.

• Ankur Sinha
• Cornelius Emase
• Emmanuel Seyman
• Guillermo Leiro
• Jakub Jelen
• Jona Azizaj
• Jonáš Hubený
• Justin Wheeler
• Mat Holmes
• Matthew Miller
• Misia Mary
• Shawn Dunn
• Vít Smolík
• Vittorio Cioe

This revamp project was in a development hell for quite some time. It was able to come out of it thanks to those listed above and countless others who have helped maintain the project for the past fourteen years or so. It is now time for me to pass this torch on to others who can help maintain this.

The project codebase currently lives on the Fedora Infrastructure's GitHub namespace. Please consider providing feedback and contributing changes to help maintain the projects. You can also hang out with us in the Fedora Badges chat room on Fedora Project's Matrix server to learn more.

Go on - give it a try!

The production deployment should be live by the time this article is publicly available. Head over to Fedora Badges to explore the refreshed experience. As it might be a little rough around the edges in the starting days, please bear with us while we hammer down the oddities with your useful reports.

Your input influences what comes next to the Fedora Badges application service. Please consider giving it a try right now and let us know what you think!

19 Aug 2026 8:00am GMT

Hoy me topé con un artículo bien fregón publicado por Sreenath en It's FOSS: Looking Beyond Tmux and Screen: 8 Terminal Multiplexers Worth Trying. De entrada, quiero darle todo el crédito a ese gran artículo y a su autor. La neta, te invito a que vayas y le eches un ojo a su trabajo original, porque plantea un panorama excelente sobre cómo ha evolucionado la gestión de terminales en el ecosistema FOSS.

Ahora bien, como usuario y apasionado de Fedora Linux, me di a la tarea de aterrizar esa lista completa al terreno de Fedora. Porque una cosa es que una herramienta exista en GitHub, y otra muy diferente es saber cómo se instala, si está en los repositorios oficiales, si vive en Copr o si requiere bibliotecas adicionales para correr al cien en tu máquina fedoriana.

Aquí te traigo la guía completa y probada empíricamente en Fedora de cada una de estas opciones, desde los veteranos de batalla hasta la nueva generación impulsada por Rust, Go, aceleración por GPU y agentes de Inteligencia Artificial.

# como root
dnf -y install tmux

# como root
dnf -y install screen

# como root
dnf -y install tmate

# Iniciar tmate y obtener credenciales de conexión
tmate

# como root
dnf -y install kitty abduco

# Crear una sesión persistente llamada "servidor"
abduco -c servidor bash

# como root
dnf -y copr enable sramanujam/zellij
dnf -y install zellij

# Instalación directa del binario oficial de Zellij
bash <(curl -L zellij.dev/launch)

# Iniciar Zellij
zellij

# como root
dnf -y copr enable wezfurlong/wezterm-nightly
dnf -y install wezterm

# como root (si faltan utilerías de compresión)
dnf -y install curl tar gzip

# Descargar e instalar TUIOS
curl -fsSL https://raw.githubusercontent.com/Gaurav-Gosain/tuios/main/install.sh | bash

# Iniciar TUIOS
tuios

# O ejecutarlo con un tema específico
tuios --theme dracula

# Descargar e instalar Boo mediante su script oficial
curl -fsSL https://raw.githubusercontent.com/coder/boo/main/install.sh | sh

# Crear una sesión en segundo plano
boo new mi-tarea

# Reengancharse a la sesión
boo attach mi-tarea

# como root: instalar dependencias de renderizado
dnf -y install libxcb libX11 libxkbcommon-x11 vulkan-loader libglvnd-egl

# Descargar y extraer Okena
curl -fsSL https://github.com/contember/okena/releases/download/v0.28.0/okena-linux-x64.tar.gz -o /tmp/okena.tar.gz
tar -xzf /tmp/okena.tar.gz -C /usr/local/bin
chmod 700 /usr/local/bin/okena

# Lanzar interfaz de Okena
okena

# Inspeccionar comandos del cliente CLI
okena --help

# como root: instalar dependencias de entorno gráfico
dnf -y install fuse-libs libadwaita gtk4 libX11 fontconfig

# Descargar el AppImage oficial
mkdir -p ~/.local/bin
curl -fsSL https://github.com/no1msd/seance/releases/download/v0.1.4/seance-0.1.4-x86_64.AppImage -o ~/.local/bin/seance
chmod 700 ~/.local/bin/seance

# Iniciar ventana principal de Séance
~/.local/bin/seance

# Controlar sesión desde CLI
~/.local/bin/seance ctl --help

18 Aug 2026 11:25pm GMT

18 Aug 2026 7:11pm GMT

Most of GNOME 51 is now packaged for Fedora 45. Starting today and running through the end of the week, we will be running our traditional Fedora Test Day for GNOME. If you are a Fedora user, you can help us find last-minute integration issues and iron out what's going to become the stable Fedora 45 release.

You can either boot the latest Fedora 45 image (nightly) in a virtual machine or update an existing test setup. Follow our guided test matrix, try out different features, and record your results. Even testing for 15 minutes and reporting a single issue makes a huge difference.

Visit https://fedoraproject.org/wiki/Test_Day:2026-08-17_GNOME_51_Desktop for more info. You can join the Fedora Workstation Matrix chat channel if you have more questions.

17 Aug 2026 8:21am GMT

Across the various Fedora groups, the overarching focus this week was on the successful Fedora 45 mass branching and its subsequent release preparations, which drove extensive testing, mass rebuilds (particularly for the RISC-V architecture), and CI/CD validation efforts. Concurrently, infrastructure and engineering teams were heavily engaged in major system upgrades, notably migrating services to RHEL 10, executing planned server outages, transitioning repositories to Forgejo, and implementing network blocklists to mitigate aggressive automated scraping that temporarily disrupted operations. Policy and governance updates were also a central theme, as the Council and FESCo worked to finalize the Fedora Forge Usage Policy, establish new Conflict of Interest guidelines, and address community concerns regarding AI-integrated software and regulatory liability under the EU Cyber Resilience Act. Finally, routine ecosystem maintenance and security remained high priorities, evidenced by the active processing of non-responsive maintainers, Out-of-Band security patching for vulnerabilities like the "Zapscape" kernel flaw, and ongoing dependency and macro improvements across language stacks like Python and Go.

Announcements

On the development and infrastructure front, Fedora 45 successfully completed its mass branching on August 11 (following an initial notification), placing the release into a post-branch freeze until a successful compose. Change owners were also reminded that all F45 changes needed to be testable by August 11. Contributors should prepare for a six-hour planned infrastructure outage on August 20 for server upgrades and RHEL 10 migrations. Policy updates are also underway, with the Council seeking feedback on the proposed Fedora Forge Usage Policy for the project's internal Forgejo instance. In broader ecosystem news, Mark J. Wielaard was honored with the Distinguished Service Award in Software Freedom by the Software Freedom Conservancy for his decades of foundational work on tools like Valgrind, elfutils, and Sourceware.

For those looking to get involved, the Fedora QA team is calling for volunteers for the upcoming Fedora 45 Test Days (detailed further in a Fedora Magazine article), starting with GNOME 51 on August 17 and followed by testing for RPM 6.1 and installation media. If you are a newcomer unsure of where to start interacting with the community, Episode 058 of the Fedora Podcast provides a comprehensive guide to Fedora's communication channels. Finally, users can check out a new tutorial on how to monitor NVMe and SSD drive health using Performance Co-Pilot (PCP).

Council

This week, the Council focused heavily on community policies and governance processes. Significant progress was made on the Fedora Forge Usage Policy, with the Council agreeing to adjust guidelines around Personally Identifiable Information (PII) and dropping the automated repository archival rule in favor of a mandatory "tickets" contact repository for organizations. Additionally, the Council agreed to propose a new Conflict of Interest guideline requiring neutral oversight during private decisions involving access rights.

Other major topics included a proposal by Red Hat to act as the Open Source Software Steward for Fedora under the EU Cyber Resilience Act (CRA) to shield volunteer contributors from regulatory liability. The community also discussed user concerns over AI features embedded in packaged software, clarifications to the AI-Assisted Contributions Policy, and an updated draft of the Fedora Innovation Lifecycle to create a sandbox for large experimental changes.

Decisions

• Agreed to update the Fedora Forge Usage Policy to include a short sentence on handling Personally Identifiable Information (PII) under the Code of Conduct section, address remaining feedback in a v.3 draft, and allow one more week of community review before voting.
• Agreed to propose a new Conflict of Interest guideline for governance groups, stating that private decisions regarding access rights should require mediation or oversight from project leadership (FPL/FCA/FOA) if a conflict of interest exists, and to gather community feedback before formalizing the change.

See the detailed report for the Council team.

Learn more about the Council team.

FESCo

This week, FESCo held one meeting, participated in three forum discussions, and handled 19 tickets. During the meeting, FESCo noted that the completion deadline and mass branching for Fedora 45 had arrived, and briefly discussed the need for mitigations against aggressive automated scraping on the src.fedoraproject.org infrastructure. On the forums, community members initiated a discussion on whether Fedora needs a formal policy or labeling system for packages that introduce AI-powered features, highlighting concerns about data privacy and unexpected behavior.

A significant portion of FESCo's activity in tickets involved voting on Change proposals for F45 and F46, resulting in the approval of several new features including a WebUI installer for Fedora Atomic, the deprecation of the NIS profile in authselect, and the introduction of a new encapsule developer container tool. Additionally, FESCo processed multiple non-responsive maintainer tickets, resulting in the orphaning of some packages and the assignment of new maintainers to several critical components like thermald and mcelog.

Decisions

• Approved Change: Web Based Remote Installation Support for Atomic Desktops (Ticket #3670).
• Approved Change: Anaconda WebUI Fedora Atomic (Ticket #3666).
• Approved Change: Encapsule isolated devel containers (Ticket #3668).
• Approved Change: IBus 1.5.35 (Ticket #3669).
• Approved Change: Authselect Remove NIS Profile (Ticket #3662).
• Approved Change: Disable in Kernel Crypto Userspace API Phase 1 (Ticket #3667).
• Approved Change: Enable systemd-oomd and zram swap for CoreOS (Ticket #3661).
• Approved Change: Sequoia openpgpverify (Ticket #3660).
• Approved an updates policy exception for python-cloudflare (Ticket #3674).
• Approved a one-time updates policy exception for thermald across all Fedora branches to fix power management issues (Ticket #3673).
• Approved the non-responsive maintainer process for the owner of python-avocado and python-aexpect, leading to the packages being orphaned (Ticket #3659).
• Approved adding new co-maintainers for thermald, libfprint, fprintd, and fwts under the non-responsive maintainer policy (Ticket #3672).

See the detailed report for the FESCo team.

Learn more about the FESCo team.

Ambassadors

This week, the Ambassadors group received a single announcement regarding the Call for Sessions for the Everything Open 2027 conference. Fedora contributors are encouraged to submit proposals for talks or tutorials relating to Linux, open source, security, or operations by September 6, 2026. For more details, see the mailing list post.

See the detailed report for the Ambassadors team.

Learn more about the Ambassadors team.

Workstation / GNOME

This week, the scheduled Workstation Working Group meeting was cancelled due to a scheduling conflict. The primary discussion in the community centered around the future of the Ptyxis terminal emulator in Fedora, as its original author confirmed he is no longer maintaining the project.

Community members discussed potential alternatives to replace Ptyxis, including Ghostty and GNOME Console. To determine an official path forward and prevent wasted effort by community translators on an abandoned upstream project, a formal ticket was filed with the Workstation Working Group.

See the detailed report for the Workstation / GNOME team.

Learn more about the Workstation / GNOME team.

Server

During the week of August 10-16, 2026, the Fedora Server group focused on Fedora 45 branched release testing and documentation restructuring. The group celebrated the availability of group-wide CI/CD runners for the first time. Significant discussions were held regarding the Home Server spin-off, specifically evaluating a new virtualized Kiwi development and testing environment.

In documentation, the group decided to streamline by merging tutorial and use-case files into a single "Use cases" section. Testing for F45 is actively underway, though a partition type issue in the VM build requires a fix.

Decisions

• The documentation structure will be updated by creating a new "use cases" section that merges all use-case and tutorial files, leading to the deletion of the dedicated "Tutorials" section.
• The Working Group will finalize the specific restructuring details for the post-installation documentation sections in the related tracking ticket and vote on it during the next meeting.
• All working group members are requested to test the new virtualized build environment by following the Home Server README to build a dummy Fedora image.

See the detailed report for the Server team.

Learn more about the Server team.

Infrastructure

This week, the Infrastructure team focused heavily on migrating services to RHEL 10, scheduling a major 6-hour outage for August 20 to handle mass updates, reboots, and VM reinstallations. To combat severe scraping traffic on Fedora infrastructure (which temporarily spiked server loads and disrupted Anubis on Pagure), the team successfully implemented a new user-agent blocklist. The team is also officially migrating the Matrix moderation bot to Fedora's OpenShift infrastructure, alongside drafting new policies for "official" Matrix rooms. Finally, the legacy retrace.fedoraproject.org server is being decommissioned due to a lack of maintenance.

Decisions

• A 6-hour infrastructure outage is scheduled for August 20 at 20:00 UTC for mass updates, reboots, and RHEL 10 migrations.
• The unmaintained retrace.fedoraproject.org server will be shut down and decommissioned.
• The primary rsync servers have been switched to the BBR congestion control algorithm to improve download speeds.
• The Fedora Matrix moderation bot will be officially migrated to Fedora Infrastructure (@moderation:fedoraproject.org).

See the detailed report for the Infrastructure team.

Learn more about the Infrastructure team.

Release Engineering

This week, the Release Engineering team successfully completed the mass branching of Fedora 45 off of Rawhide, with Rawhide officially transitioning to Fedora 46. Concurrently, the mass re-signing process for Fedora 45 packages and the generation of the Fedora 47 IMA key took place. Additionally, the team finalized the migration of all Release Engineering repositories to Forgejo (fedora-scm-requests).

Other notable activities involved fixing an early signing issue for ELN packages, updating staging environments for koji-image-builder testing, and refining internal tools, such as creating a dedicated team to validate SCM requests and reduce notification spam. Maintainers are also reminded to use the new fedpkg request-unretirement feature instead of filing Releng tickets for routine package unretirements.

Decisions

• Fedora 45 was successfully branched from Rawhide, making Rawhide officially Fedora 46.
• Package maintainers no longer need to open Release Engineering tickets for package unretirements; they must now use the fedpkg request-unretirement command (requires fedpkg v1.48+).
• All Release Engineering repositories have been fully migrated to Forgejo.
• A new group (forge-releng-scm-validators) was established to handle SCM requests directly, resolving the issue of excessive pings to all members of the releng organization.
• The Fedora 43 signing key was removed from the coreos-pool and replaced with the Fedora 46 key.
• Nonresponsive maintainer processes were executed for the user cleber, resulting in the orphaning of their packages.

See the detailed report for the Release Engineering team.

Learn more about the Release Engineering team.

Quality

The Quality group focused on system performance, package default configurations, and preparations for the Fedora 45 release. Significant attention was brought to performance and power efficiency regressions caused by the switch to tuned-ppd, prompting discussions on how to better adjust the default TuneD profiles. Additionally, community testers successfully verified a critical GRUB Out-of-Memory fix in Rawhide.

In Quality Engineering (QE), early manual validation testing for Fedora 45 has started and already uncovered several significant bugs. The team also prepared tooling for the upcoming release, testing Issuebot in production and marking it ready for F45.

Decisions

• Issuebot has been successfully tested in production and is formally ready to run for the Fedora 45 release cycle.
• The GRUB Out-of-Memory fix was verified to work in Rawhide, allowing the pending rollout to Fedora 44 to proceed.

See the detailed report for the Quality team.

Learn more about the Quality team.

Design

Between August 10 and August 16, 2026, the Design team continued to refine key graphical assets for Fedora projects and internal tools, alongside ongoing UX work for the Fedora Design Docs revamp. Major discussions revolved around finalizing the character details for the LoLa AI Package Manager mascot and aiming to complete avatars for the Fedora Matrix bots by the end of the current sprint. Additionally, historical design assets were preserved through a repository migration from Pagure to the active Forge.

Decisions

• Migrated the legacy designassets repository from Pagure to the Design organization on Forge to preserve historical content and history.
• Utilized the Matrix ID @admin:fedoraproject.org as the official handle for the newly rolling-out moderation bot, which will require an avatar.

See the detailed report for the Design team.

Learn more about the Design team.

Docs

The Docs team met to discuss ongoing efforts to clean up outdated Fedora Wiki pages, exploring automated approaches using the MediaWiki API to replace tedious manual deletions. They also evaluated a new experimental CI site builder relying on Podman and discussed adopting the Vale linter, deciding to introduce it as a recommendation for local authoring before enforcing it in CI. Concurrently, a community forum discussion took place regarding the documentation and rationale behind recommending a separate /boot partition in Fedora installations. Team tickets tracked a new membership request, a broken link in the Server test results wiki page, and the extensive historical wiki cleanup effort.

Decisions

• The Vale linter will be introduced as a recommended tool for local authoring rather than a strict CI requirement to avoid blocking contributors with excessive errors.
• Mass deletion of obsolete Docs-related wiki pages (such as Fedora 8 and 11 guides) will continue, with script-based automation via the MediaWiki API being actively explored to streamline the process.

See the detailed report for the Docs team.

Learn more about the Docs team.

Internationalization

This week, the Internationalization group received a cross-posted invitation to speak at the Everything Open 2027 conference. Community members are encouraged to submit session proposals covering topics like Linux, open source, AI, security, and operations before the September 6, 2026 deadline.

See the detailed report for the Internationalization team.

Learn more about the Internationalization team.

Legal

This week, the Legal group discussed whether Copr projects are permitted to download and use proprietary software, specifically the NVIDIA CUDA toolkit, during the build process for otherwise free and open-source packages like cuda-python. The primary concern raised was that utilizing proprietary dependencies during a build could inadvertently include proprietary code in the resulting binaries, such as through inlined headers. The prevailing consensus was that this practice is not allowed if it results in the distribution of content that violates Fedora's allowed licensing rules.

Decisions

• Software built, hosted, and distributed in Copr must be governed entirely by an acceptable Fedora license. Downloading proprietary software (like the NVIDIA CUDA toolkit) during a Copr build process is generally unacceptable if it causes the resulting binary to include proprietary content, such as inlined code from proprietary headers.

See the detailed report for the Legal team.

Learn more about the Legal team.

COPR

A scheduled outage for the COPR servers was announced for 2026-08-12 at 07:30 UTC, lasting approximately three hours. The downtime allowed the team to update COPR packages to newer versions, providing bug fixes and new features to the general Linux community using the build service.

Community members with questions or issues were encouraged to use the Fedora Build System Matrix channel (#buildsys:fedoraproject.org) or comment on the associated infrastructure ticket.

Learn more about the COPR team.

EPEL

This week, the EPEL group focused heavily on repository architecture and package updates. The Steering Committee unanimously approved the "de-z-ification" of EPEL 10, aligning its repository structure with the upcoming EPEL 11 release by utilizing the $stream variable for CentOS while leaving RHEL without a suffix.

In package news, maintainers announced the migration of libgit2 dependents in EPEL 9 and EPEL 10 to the supported v1.9 branch to address security vulnerabilities, as well as minor updates to uv and ruff in the EPEL 10.3 testing repositories.

Decisions

• The EPEL Steering Committee unanimously approved the "de-z-ification" of EPEL 10. CentOS streams will use suffixed repository paths (e.g., epel-10s) while RHEL uses unsuffixed paths (e.g., epel-10), aligning with the approved EPEL 11 design.
• Packages depending on libgit2 in EPEL 9 and EPEL 10 will be migrated from the obsolete v1.7 branch to the supported v1.9 branch via pull requests.

See the detailed report for the EPEL team.

Learn more about the EPEL team.

ELN

The ELN group met this week to discuss recent updates, including the publication of bootc images, the minimization of go-vendor-tools for RHEL 11, and variant reorganizations such as moving Live images to a new AltImages variant and adding a new Extensions variant. The group also noted the F45 branching process, which temporarily paused builds, and highlighted that the next branching in six months will coincide with the RHEL 11 branching.

Additionally, the group discussed mitigating database bloat in Koji caused by failing draft build retries. A proposal was also made to adopt a separate GPG key for ELN content starting with Fedora 46 to reduce the frequency of key rotations from twice a year to once every three years.

Decisions

• Pursue a dedicated GPG key for ELN content starting with the F46/EL11 branching cycle to reduce key rotations, initiating the process by filing a releng ticket.
• Deploy a fix to the build sync tooling to prevent retries of consistently failing draft builds from rapidly filling up the Koji database.

See the detailed report for the ELN team.

Learn more about the ELN team.

Atomic

The Atomic group had a quiet week. During a brief meeting, members noted that ongoing Konflux integration work for Atomic Desktops is continuing. On the forums, a community member inquired about /opt and /usr/local functioning as symlinks in Silverblue and asked whether future Fedora bootc images will transition to using regular directories instead.

Learn more about the Atomic team.

CoreOS

CoreOS met once this week to discuss the Fedora 45 release schedule and a severe kernel vulnerability. Fedora 45 recently branched from Rawhide, and the team is preparing the necessary updates for coreos-installer and bootc images, alongside monitoring for F46 key signing issues in Rawhide.

The team also reviewed the recent "Zapscape" kernel vulnerability (CVE-2026-64561). They decided to issue an out-of-band kernel update for the testing and next streams to mitigate the issue for VM workloads immediately, rather than waiting for the scheduled stable release next week.

Decisions

• Issue an out-of-band kernel update for the testing and next streams to address the Zapscape vulnerability (CVE-2026-64561) prior to the next scheduled stable release.
• Use a package override via GitHub actions to fast-track the fixed kernel without promoting the entire testing-devel/next-devel stream.

See the detailed report for the CoreOS team.

Learn more about the CoreOS team.

ARM

During this week, the ARM group had a brief discussion regarding kernel availability for the Raspberry Pi 5. A community member inquired about a Fedora 44 (F44) kernel, noting the reliability of the current F43 kernel updates. It was confirmed that F44, F45, and Rawhide kernels are already available for the device in the existing COPR repository.

Learn more about the ARM team.

Alternative Images

In their recent meeting, the Alternative Images group announced that RISC-V tags and targets have been successfully set up, representing a major first step toward creating new RISC-V images. Furthermore, Kiwi descriptions for RISC-V have been provided by Andrea.

The group is designating the upcoming week as "image week." During this time, they will conduct their regular quarterly image updates and officially begin generating RISC-V images specifically for QEMU virtual machines and P550 hardware.

Decisions

• To begin generating RISC-V images specifically targeting QEMU and P550 hardware during the upcoming week.
• To proceed with the regular quarterly image updates next week.

Learn more about the Alternative Images team.

AI & ML

The AI & ML SIG met to discuss the upcoming ROCm 7.14 update for Fedora 46 and the use of the pi-coding-agent tool (available in Fedora 45) for automating day-to-day packaging review tasks. A major point of discussion was a proposal to split the AI/ML SIG into two distinct groups (packaging vs. end-user AI adoption). The group unanimously decided against the split, opting to maintain a "big-tent" approach while improving documentation to clarify roles. In other news, an all-new Electron RPM was submitted to unblock Podman Desktop in Fedora, alongside updates to Podman Desktop in COPR and a proof-of-concept Atomic Fedora CSB bootc image.

Decisions

• The proposal to split the AI/ML SIG into two separate groups (Packaging and AI Use) was rejected; the SIG will maintain a unified, "big-tent" structure.
• Clarified that membership in the general ai-ml-sig FAS group does not grant packaging commit rights, maintaining a clear security boundary for compliance efforts like the EU Cyber Resilience Act.

See the detailed report for the AI & ML team.

Learn more about the AI & ML team.

RISC-V

The Fedora 45 RISC-V mass rebuild is 85% completed (around 20,000 packages), significantly aided by community members and Red Hatters who contributed new builders to parallelize the process. You can view the rebuild status numbers here. Other focus areas included investigating a failed LLVM build with RISC-V patches, co-writing Koji querying scripts, and exploring "Agentic SDLC" ideas for automated FTBFS triage and image boot testing.

A major challenge this week involved AI scrapers bringing down the Koji hub over the weekend, which resulted in numerous build failures.

See the detailed report for the RISC-V team.

Learn more about the RISC-V team.

Security

The Security group held an open-floor meeting this week, where members discussed their roles, kernel maintenance, and the upcoming packaging of module-jail for Fedora. On the forums, a mass scan report from OpenScanHub was published for Fedora 45 Critical Path Packages, calling for maintainers to review AI-flagged security findings. Additionally, a complex architectural issue regarding systemd-run0 and SELinux was brought to the mailing list, with a request for community input on the best path forward.

Decisions

• Justin Forbes will maintain the Fedora package for module-jail and work to integrate it into the proper repositories as an opt-in security feature.

See the detailed report for the Security team.

Learn more about the Security team.

Go

The Go SIG met this week and primarily discussed the upcoming Go 1.27.0 release, which is expected soon alongside embargoed CVE patches for the 1.26 and 1.25 branches. The group also discussed architecture support, noting that i686 (32-bit x86) builds are increasingly being excluded from specific packages, though linux/386 remains a first-class port in the Go ecosystem and cannot be entirely purged yet due to system dependencies.

Decisions

• The SIG will run a mass prebuild once Go 1.27.0 is released to identify and fix any broken packages before requesting a mass rebuild.

See the detailed report for the Go team.

Learn more about the Go team.

PHP

This week, the PHP group received an update regarding an ongoing dependency resolution issue in EPEL where php-devel incorrectly pulls in php8.4-devel instead of the default PHP 8.3 stack. Remi Collet reported that although the package itself has been fixed, both the affected and fixed versions currently coexist in the EPEL-10.3 buildroot, meaning the issue remains unresolved.

Learn more about the PHP team.

Python

This week, the Python group evaluated a provisional dependency patching macro to simplify package builds and discussed formalizing its behavior. They also reached consensus on an RFC to expand automatic python(abi) dependencies to all file types installed in Python library directories.

Additionally, discussions were opened regarding a migration strategy for the upcoming flit-core v4 release to ensure compatibility ahead of the Fedora 46 branch, and guidance was provided to packagers dealing with upstream applications that pollute the global Python namespace.

See the detailed report for the Python team.

Learn more about the Python team.

Other Discussions

This week in Fedora, there were updates to the package review process and SCM request infrastructure, along with a multitude of package updates, soname bumps, and mass branching for Fedora 45.

• Fedora Package Review Process reimagined prototype development is ongoing, with Jakub Kadl&ccaron;ík updating the Copr custom build feature implementation and support for vendored sources to inch closer to an optimal Forgejo and Packit integration.
• A new tool named Kiritan was introduced by Fyra Labs as a Rust-based alternative to createrepo_c, promising significantly faster execution and lower RAM usage.
• The pagure.io sunset & scm-requests migration is officially finished for SCM requests, and the team is now finalizing a static page mirror and a workaround for private issues.
• In the binary content in node_modules thread, Gordon Messmer announced a major update to npm2rpm, providing new test packages for evaluating node dependency bundling.
• A non-responsive maintainer check was initiated by Federico Pellegrin to contact Lubomir Rintel (lkundrak) due to unanswered PRs and bugs across multiple packages.
• A discussion about compose failures with too many files concluded that the issue is likely due to a file descriptor leak in Bodhi rather than system file limits being configured too low.
• The community celebrated as Mark J. Wielaard received the Distinguished Service Award in Software Freedom at FOSSY 2026, recognizing his decades of service maintaining essential tooling like Valgrind, elfutils, and Sourceware.
• Maxwell G started a nonresponsive maintainer check for Sandro (gui1ty), noting a lack of activity since late 2025 across 77 packages.
• Tomas Kopecek proposed to drop Python 2 support from remaining Koji components in upcoming releases (1.37 or 1.38), creating a legacy branch for security updates instead.
• Other discussions this week included a call for sessions for Everything Open 2027, a planned infrastructure outage on August 20, the planned shutdown of the unmaintained retrace.fedoraproject.org service, the successful completion of the Fedora 45 Mass Branching (after its initial announcement), a reminder for the F45 Changes Testable deadline, reports on findings by static analyzers for F45 Critical Path Packages, and an error in the procps Ukrainian translation file.

Orphaning packages

• Gabriel L. Somlo is orphaning yosys, nextpnr, and related packages, which were subsequently picked up by Alexander F. Lent.
• Peter Hutterer is orphaning evtest, evemu, and several X11 utilities, with xkill already claimed by Artur Frenszek-Iwicki.
• An automated report detailed a large list of orphaned packages looking for new maintainers before they are automatically retired.
• Lumír Balhar is orphaning python-pipdeptree due to upstream shifting the main engine to Rust, complicating its dependency chain.

Package updates

• Pavel Raiskup announced the release of Mock v6.8 and mock-core-configs v45.1, featuring a new separate_check config option and a system_monitor plugin, though manual side-tag builds were needed to bypass some Bodhi gating issues.
• Marek Kasik prepared a poppler soname bump to 26.08.0 in Rawhide, coordinating rebuilds with dependent packages like Inkscape and LibreOffice.
• Luya Tshimbalanga announced the f45-backgrounds update, detailing fixes to allow lossy JPEG XL wallpapers to correctly render on KDE Plasma.
• Xavier Bachelot announced a libnfs 7.0.0 soname bump, providing a side tag for dependent package maintainers to rebuild against.
• Kaleb Keithley is updating Apache Thrift to 0.24.0, which includes a SONAME bump in rawhide.
• Milan Crha announced a libedataserver soname version bump for the 3.61.2 release in Rawhide.
• Jerry James notified the list about an upcoming z3 version 5.1 soname bump.
• Michael J Gruber announced a soname bump for girara, zathura, and mupdf to bring the latest versions to Fedora via side-tags.
• Ondrej Nosek released rpkg-1.70 and fedpkg-1.48, noting that the projects are now hosted on Fedora Forge and documentation is available on Readthedocs.
• Fabio Valentini warned about an upcoming pygit v1.20.0 update that removes several deprecated symbols and breaks backwards compatibility.

New contributor introductions

• Dirk Nehring introduced themselves as a long-time Linux user and VDR plugin author, looking for a sponsor to help package and maintain VDR plugins in Fedora.

Contribution opportunities

Community members with hardware access or environments for testing can immediately contribute to quality assurance efforts across various groups without needing prior team membership. Testers are needed to validate Fedora 45 bare-metal and VM builds, monitor Rawhide for CoreOS key signing breakages, and test new out-of-band CoreOS kernel updates addressing Zapscape. Users with specific hardware can test kernels on Raspberry Pi 5 or prepare to test upcoming RISC-V and P550 alternative images. Additionally, general contributors can test pi-coding-agent in Fedora 45, evaluate the provisional Python %pyproject_patch_dependency macro, run the Home Server README image build, clone the experimental docs-fp-o-ci-test site builder, or evaluate the separate_check feature in Mock 6.8. Those experiencing performance drops on modern hardware can also assist the Quality team in debugging TuneD configuration profiles.

Developers and packagers can step up to adopt orphaned packages (such as python-avocado, evtest, bottles, and Zim), or sponsor new maintainers like Dirk Nehring (Ticket #13470 for rust-plotters-backend). There is a high demand for fixing Fails To Build From Source (FTBFS) issues during the Go 1.27.0 mass prebuild, RISC-V LLVM patches, and EPEL migrations. Scripting opportunities include refining mass rebuild scripts (Ticket #13428, PR #13051), improving Bodhi update checks (Ticket #13468), assisting with a test assets repository server, packaging Zig applications for Workstation, or designing UI-side Ansible tasks for Zabbix. Additionally, package maintainers should review the August 2026 OpenScanHub report to resolve static analyzer findings or take over the retrace.fedoraproject.org service.

Contributors with writing or visual design skills can pick up valuable tasks without deep technical setups. The Design team welcomes interns and new contributors to illustrate Community Personas or create event flyers using tools like Inkscape. Writers can restructure the Server post-installation guide into self-contained AsciiDoc topics, write Kickstart coverage for dnsmasq, clean up legacy wiki pages (Issue #43), fix documentation links like relval (Issue #61), or propose content to the AI/ML documentation (Issue #38). Contributors can also clear legacy pagure.io links from the Fedora Ansible repository comments. Translators, however, are asked to pause localization on Ptyxis until a new default Workstation terminal is finalized.

Anyone in the wider community can provide valuable feedback on overarching project governance, legal policies, and community advocacy. Open discussions seeking input include the Fedora Forge Usage Policy, the Innovation Lifecycle proposal, Workstation WG issue #520 regarding terminal emulators, and the overarching policy on packages containing AI-powered features. Legal experts can evaluate open-source licensing edge cases involving dynamic linking or draft the GPU Acceptable Use Policy (Issue #35), while SELinux experts can advise on systemd-run0 integration. Finally, all contributors are encouraged to share their Fedora-related expertise by submitting session proposals to the Everything Open 2027 conference before September 6, 2026.

17 Aug 2026 7:53am GMT

17 Aug 2026 12:00am GMT

16 Aug 2026 8:30am GMT

Another week gone by, hard to understand that it's almost fall here now. Here's a recap of things from this last week:

15 Aug 2026 7:59pm GMT

15 Aug 2026 7:57am GMT

Fedora 45 has several system-level changes that need testing on real hardware. The first test day up is GNOME 51, starting on 17 August, with more events planned for RPM 6.1, installation media and others. You can participate with a VM for most tests; some hardware-specific testing is more useful on a real machine.

Details are contained in this article.

Fedora 45 is bringing several changes that deserve testing beyond CI and automated test suites. Here are some of the bigger ones:

• RPM 6.1: update to 6.1, enforced signature checking, and DNF repo configs relocating to /usr.
• OpenSSL 4.0 - a major version bump that could affect anything doing TLS.
• Boot and live media are being rebuilt from scratch with image-builder. This changes how the images are produced, so we want to make sure they still boot and install correctly across a range of hardware and virtualization setups.
• kmscon replaces the kernel VT console (fbcon) as the default.
• Python 3.15, GRUB EFI for Confidential Computing, and more.

Why we need community testing

Automated tests catch regressions in known scenarios, but they won't tell us if the new boot.iso works on your particular laptop, or if enforced RPM signature checking breaks a workflow nobody on the team thought of. We need people trying this on real machines and in real scenarios.

That's what test days are for. A few days focused on a specific change, developers on Matrix to help debug, and anyone can show up and run through the test cases. You don't need to be a Fedora QA expert. If you can install Fedora, reproduce a problem and report what happened, you can help.

What we're planning for F45

At our July 20 Quality meeting (transcript), we went through the ChangeSet and picked out the changes that would benefit most from community testing. That turned into a planning ticket on Forge with individual tickets for each event.

GNOME 51 Desktop - August 17-21 is the first test day this cycle and it's happening right now . Desktop, graphics, peripherals, core applications. If you're reading this in time, jump in. (#GNOME_51_Desktop)

I18n test week -September 7-13 input methods, locales, keyboard layouts. . (#924)

RPM 6.1 - NSS support for user/group lookups is back, queries work again during transactions, new macro modifiers for packagers, and better rpmkeys verification output. Looks like a smooth update, but RPM touches everything - worth making sure nothing slipped through. (#917)

Installation media - boot.iso and live images, physical hardware, VMs. Try booting the new images on whatever hardware you have. Does the installer work? Does the live environment behave? (#918)

KDE - likely KDE 6.7. (#922)

Cockpit - it's been years since the last Cockpit test day. (#920)

GRUB EFI / Confidential Computing - relevant mainly to specific hardware and VM environments. (#919)

The list isn't final. We're still looking at kmscon, OpenSSL 4.0, CoreOS, and Kernel 7.2. Keep an eye on testdays.fedoraproject.org for the current schedule.

What kind of testing helps most

Try upgrading your system to the latest packages. Boot the new boot.iso on physical hardware. Test suspend/resume, Wi-Fi, external displays, NVIDIA/AMD/Intel graphics, or whatever hardware you actually use. Each test day has a wiki page with specific test cases, but your own daily workflows are often where the interesting bugs hide.

You need a Fedora Account to report results. Pick a test day from the schedule, follow the wiki instructions, report through the test day app, and if you find something odd, come talk to us on Matrix in #test-day:fedoraproject.org.

The test day app itself is open source at quality/testdays-web on Forge. If something about it bugs you or you have an idea, file a ticket.

Propose a test day

This doesn't all have to come from us. If you maintain a package with a big change in F45, or you see something in the ChangeSet that you think needs broader testing - propose a test day. Create a ticket at forge.fedoraproject.org/quality/tickets, tag it "test days", and tell us what you'd like to test. You don't need test cases or wiki pages ready. The QA team will help with that.

Testing beyond test days

Test days are focused events around specific changes, but testing Fedora is something you can do any day. fedora-easy-karma is a CLI tool that picks up testing updates already installed on your system and lets you submit karma to Bodhi right from your terminal. See the installation instructions to get started. Like the test day app, it's an open source project hosted on Forge - feel free to report issues or suggest features.

Links

• Test day schedule and results
• Fedora 45 ChangeSet
• F45 test day planning ticket
• Test Days wiki
• Matrix: #test-day:fedoraproject.org
• Mailing list: test@lists.fedoraproject.org

Catch you in #test-day on Matrix.

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.

14 Aug 2026 5:22pm GMT

Release Candidate versions are available in the testing repository for Fedora and Enterprise Linux (RHEL / CentOS / Alma / Rocky and other clones) to allow more people to test them. They are available as Software Collections, for parallel installation, the perfect solution for such tests, and as base packages.

RPMs of PHP version 8.5.10RC1 are available

• as base packages in the remi-modular-test for Fedora 43-44 and Enterprise Linux ≥ 8
• as SCL in remi-test repository

RPMs of PHP version 8.4.25RC1 are available

• as base packages in the remi-modular-test for Fedora 43-44 and Enterprise Linux ≥ 8
• as SCL in remi-test repository

ℹ️ The packages are available for x86_64 and aarch64.

ℹ️ PHP version 8.3 is now in security mode only, so no more RC will be released.

ℹ️ Installation: follow the wizard instructions.

ℹ️ Announcements:

• PHP 8.5.10RC1 available for testing
• PHP 8.4.25RC1 available for testing

Parallel installation of version 8.5 as Software Collection:

yum --enablerepo=remi-test install php85

Parallel installation of version 8.4 as Software Collection:

yum --enablerepo=remi-test install php84

Update of system version 8.5:

dnf module switch-to php:remi-8.5
dnf --enablerepo=remi-modular-test update php\*

Update of system version 8.4:

dnf module switch-to php:remi-8.4
dnf --enablerepo=remi-modular-test update php\*

ℹ️ Notice:

• version 8.5.10RC1 is in Fedora rawhide for QA
• version 8.6.0beta1 is also available in the repository
• EL-10 packages are built using RHEL-10.2 and EPEL-10.2
• EL-9 packages are built using RHEL-9.8 and EPEL-9
• EL-8 packages are built using RHEL-8.10 and EPEL-8
• oci8 extension uses the RPM of the Oracle Instant Client version 23.26 on x86_64 and aarch64
• intl extension uses libicu 74.2
• RC version is usually the same as the final version (no change accepted after RC, exception for security fix).
• versions 8.4.19 and 8.5.4 are planed for March 12th, in 2 weeks.

Software Collections (php84, php85)

Base packages (php)

14 Aug 2026 3:53am GMT

13 Aug 2026 10:00pm GMT

We all like to think that we're very rational and make decisions logically. We're not and we don't. Like it or not, we're humans and that comes with emotions. Frustratingly, means our very rational decisions are often greeted by other people's emotions.

People form attachments to identities, like being a user of or contributor to a project. Of course, they also form attachments to things both physical and abstract. When something goes away, they do not like it. We do not like it.

There are, of course, many rational reasons to take away something that people want and have grown accustomed to having. Many projects have long ago dropped support for the i386 CPU architecture because the hardware is less prevalent and they no longer want to bear the burden of testing and supporting a rarely-used architecture. Nobody is shipping new software for Windows 95 or Red Hat Linux 8 - those operating systems were out of date 25 years ago. You might stop hosting personal websites for contributors because that's not a scarce resource anymore. Maybe you stopped funding travel scholarships because your donation streams have dried up.

No matter how rational your decision-making process, someone will be upset about the loss of something they hold dear. (If no one cares, maybe you should have made this decision long ago.) Of course, not all of the objections will be emotionally-driven. Most decisions will have rational arguments against them - if there is only one reasonable course of action, there's no need for a decision, after all.

You don't need to get unanimous buy-in for a decision to take something away. You do want to minimize the stress the decision causes. Here are some tips that I've learned over the years:

• Prepare your rationale ahead of time. You only have one chance to give a first explanation. Make sure you give the reasons why you're making the change. Acknowledge the impact it will have on people. Point out the benefits (if any), but don't try to spin it as solely a good thing.
• Give yourself enough time. People will need time to process their feelings. Make sure the timeline allows for that.
• Make sure the key people are around for the announcement. You'll want the folks who are respsonsible for the change to be available to respond to questions and concerns in a timely manner.
• Don't try to win the argument. Answer questions, clarify ambiguities, and respond to novel concerns. You don't need to respond to every message from every person. It wastes your time and over-arguing can just get people to dig in further. And, of course, don't engage with bad faith arguments.

This post's featured photo by Matthew Henry on Unsplash.

The post Be prepared for big feelings when you take something away appeared first on Duck Alignment Academy.

12 Aug 2026 12:00pm GMT