Bug-monitoring expectations and Fedora GNOME packages [LWN.net]

By Joe Brockmeier
May 4, 2026

For a number of years, users submitting bugs reports against GNOME packages in Fedora have received an auto-reply saying that the reports were not actively monitored; users were encouraged to file bugs with GNOME upstream instead. However, that practice seems to be in conflict with the Fedora Engineering Steering Committee (FESCo) policy that package maintainers "deal with reported bugs in a timely manner". On April 28, FESCo discussed the disconnect between practice and policy; so far, it has only opted to tweak the wording of the automatic response.

Many of the GNOME packages in Fedora are maintained by members of Red Hat's desktop team. Bugs filed against some of those packages, such as gnome-disk-utility, gnome-session, and nautilus, are automatically assigned to the "gnome-sig" alias in the Bugzilla bug tracker. There are 21 members in the group, but it is unclear if all users in that group are currently active.

Nearly 750 bugs are assigned to gnome-sig as of this writing. A few of those bugs, however, were opened more than a decade ago and were reassigned to the group at some point when package ownership changed—likely because a package was "orphaned" and no other packager stepped up to claim it. When a bug is assigned to gnome-sig, it receives an automatic response that reads in part:

Bug reports for this component on Red Hat Bugzilla are not actively monitored. Please consider reporting your issue directly to GNOME at https://gitlab.gnome.org/GNOME/ to improve the chances that your issue will be resolved.

In February, Carl George opened a ticket with FESCo about the automated reply. He said that it was "entirely reasonable to encourage collaboration with upstream projects", but the response suggested that the bugs were not being monitored at all, which would indicate that the package maintainers were not meeting their responsibilities under Fedora policy. "Can FESCo provide guidance on how this should be addressed?"

Too many bugs

FESCo member Kevin Fenzi replied with a link to a Fedora Workstation discussion in 2020 that led to the automatic reply. Michael Catanzaro had opened that conversation by saying he thought that most of Fedora's GNOME developers had given up on Bugzilla: "Currently, it's where bugs go to be ignored and receive no response, including serious bugs. This status quo is unfair to users." Fedora GNOME developers were only "passingly familiar" with the packages that they own: "I checked a couple other GNOME maintainers to see how many bugs are assigned to them and found: 260, 182, 420, 511, 372." He had fewer bugs, but also owned fewer packages than most of the GNOME maintainers who were maintaining "dozens of packages".

There were just too many bugs to practically deal with, Catanzaro said. Moving them upstream took too long as well: "we'd spend so much time moving bugs that we'd never get anything else done". If the bugs were filed upstream to begin with, "there's a decent chance the bug reports won't be ignored" because the bugs go "straight to the right developers". Allan Day wondered if GNOME was the only upstream with the problem of managing Fedora bugs. Neal Gompa responded that KDE also struggled, but he thought it made more sense to file bugs with both the upstream project and Fedora: "That way Fedora processes still work, and GNOME/KDE people can focus on upstream reports."

FESCo member Fabio Valentini pointed out that GNOME changes often caused problems in Fedora that did not qualify as bugs upstream. For example, GNOME may make changes to D-Bus interfaces that introduce crashes in the Pantheon desktop environment developed for elementary OS and packaged for Fedora. He had been told that GNOME's GitLab instance was the wrong place to report those problems, because "they're just 'features, not bugs'".

Owen Taylor admitted being one of the Fedora maintainers who ignored hundreds of bugs that had been assigned to him. Looking at bugs in the Fedora Bugzilla turned up "lots of interesting and intriguing stuff" that would sometimes lead to upstream bug fixes, "but getting bugzilla anywhere close to clean would have required me to be close to full-time bugzilla triager, and not get anything else done". He wanted to teach Fedora's Automatic Bug-Reporting Tool (ABRT) to report GNOME bugs upstream; that, though, could only apply to bugs being opened when application crashes were detected. He also wanted users to receive a suggestion to report bugs upstream unless their problem seemed to be related to packaging or otherwise unique to the distribution.

The discussion continued, and a solution of sorts was finally found; in June 2023, Tomas Popela said that a Bugzilla rule would be created to automatically add a comment after a bug was filed that the user should report bugs upstream unless it was related to packaging or to Fedora's release process (e.g., if a bug would block a Fedora release). The rule was implemented in November 2023.

ABRT did not learn how to report bugs upstream and is currently in the process of being decommissioned following years of neglect. Catanzaro said that Red Hat has stopped assigning developers to work on ABRT, and no one from the community has stepped up to maintain it. The graphical-user interface component for ABRT was removed in Fedora 44 and the plan is to remove it in its entirety before Fedora 45.

Community discussion

FESCo decided, during its meeting on February 17, to open a discussion on Fedora's forum to get community input about unmonitored bug reports. Valentini started the thread and then followed up with his own opinion on the topic. He agreed that a ridiculous number of bugs were being filed against some GNOME components, but the autoresponder was not helping. Once a bug was filed, he said, people feel like their part is done "and then they're asked to go do all that again somewhere else".

George replied that policy dictated maintainers deal with bugs in a timely manner; either the policy should be changed, or the response needed to change to be in alignment with Fedora policy. Gompa said that Fedora KDE maintainers also had "a very heavy bug reporting load", but had not requested special treatment. He acknowledged that the team was "quite bad at tagging bug reports to be closed", but felt that it was not a good idea to convey to users that bug reports were ignored by default:

To me, actions like this make it feel like Fedora is not providing value to the user or the upstream. Because if maintainers aren't doing that funnel work or leveraging shared infrastructure to help improve the quality of the components they maintain, I don't know what they are doing.

Fedora is currently working on adopting Forgejo as its collaborative-development platform, which will (at some point) include using Fedora Forge instead of Bugzilla for tracking bug reports. Catanzaro said that, when that happens, users would see a report template that would direct them upstream before they open a bug with the Fedora project. He suggested that Fedora needed to focus on fixing its bug tracker and bug-report tooling to ensure that bugs were reported in the right place. "I really don't think it's realistic to expect packagers to read the downstream bug reports."

Gompa argued that telling users to go upstream was a bad idea for several reasons; there is no one-to-one mapping of components between Fedora and GNOME, and users would be interacting with developers who may or may not have influence on how quickly a fix could be delivered. George replied that, whether it was realistic or not, Fedora's current policy required packagers to read and respond to bug reports.

Change the message

After the public discussion had time to wind down, FESCo revisited the topic during its meeting on April 28 (log). FESCo decided that the first sentence in the automatic response ("Bug reports for this component on Red Hat Bugzilla are not actively monitored") would be dropped. That was implemented on April 29.

Note that this does not mean that bug reports are being any more actively monitored than before; the message has changed, but FESCo has not yet given any guidance on what should be done next. It has concluded further discussion (and, perhaps, action) would be needed because, as Valentini wrote in the meeting summary, "intentionally not monitoring bugs on bugzilla is in tension (if not conflict) with guidelines around package maintainer responsibilities."

FESCo member Stephen Gallagher said that he had followed up with Catanzaro and Matthias Clasen, and they intended to join the next FESCo meeting. If the Workstation working group adopted an issue template that directed users upstream before filing a bug report, he thought, "it will be accepted as a reasonable compromise between policy and reality".

Whatever the outcome of the meeting, it seems unlikely that it will address the core problem that Fedora's GNOME package maintainers seem to have more work than they can comfortably manage. It matters little where bugs are filed if there aren't enough hands to do the work.

to post comments

Or, stick to the policy?

Posted May 4, 2026 22:23 UTC (Mon) by Karellen (subscriber, #67644) [Link] (7 responses)

George replied that policy dictated maintainers deal with bugs in a timely manner; either the policy should be changed, or the response needed to change to be in alignment with Fedora policy.

There's a third option, in that if the maintainers don't have the resources to cover the responsibilities laid down by policy, then, as per the non-responsive maintainer policy, Gnome could be considered for orphaning and/or retiring?

Or, stick to the policy?

Posted May 5, 2026 9:01 UTC (Tue) by taladar (subscriber, #68407) [Link]

I would argue that "We don't support GNOME at all on Fedora" would still be a change in policy.

Or, stick to the policy?

Posted May 5, 2026 12:46 UTC (Tue) by ebassi (subscriber, #54855) [Link] (1 responses)

Since the same resourcing problem seems to apply to anything more complicated than a single package, how long before Fedora is unable to ship anything bigger than coreutils?

Or, stick to the policy?

Posted May 5, 2026 14:19 UTC (Tue) by zdzichu (subscriber, #17118) [Link]

That's redutio ad absurdum. There are many Fedora maintainers handling bug reports just fine.

Or, stick to the policy?

Posted May 5, 2026 14:19 UTC (Tue) by zdzichu (subscriber, #17118) [Link]

As a Fedora contributor and GNOME user since forever (early '00) I agree with that. It may be sad, but I can get used to other DE for hosting a Terminal and a browser window.

Policies it what makes Fedora Fedora, there shouldn't be an exception for GNOME.

Or, stick to the policy?

Posted May 5, 2026 16:12 UTC (Tue) by rjones (subscriber, #159862) [Link]

I think the issue highlights the issue with distributions wanting to treat themselves as separate projects from upstream processes and the problems it causes. Namely the confusion and issues that occur for end users when distributions make substantial changes to software.

If the changes they created caused the bug then the distribution is the correct place to file the bug. But if the bug is present in the upstream software then the bug report should be filed there. However end users are often the people least equipped with the prerequisite information necessary to make that sort of judgement, yet it is considered their duty to be the ones to file the bugs with useful and relevant information in the first place.

Which then makes it necessary to have somebody on the distribution level to triage the bugs and make the decisions on behalf of the users on where the bug ultimately gets sent to. They are the only ones that reliably decide if a bug is something they created or upstream created.

HOWEVER... if the distribution works very closely with upstream then that process is likely inappropriate.

IF Fedora closely aligns it's release, configuration, and development process of its Gnome desktop with the Gnome project itself then that process can be treated as a extension of the upstream Gnome project. Essentially the Fedora Gnome maintainers should, ideally, be volunteers as part of Gnome project itself. Be the experts in how Gnome should be packaged for RPM OSes and have their packaging effort be a sort of extension of the Gnome project itself rather then just solely part of the Fedora project. They then can collaborate with other distributions that consume Gnome in RPM format and if possible have those maintainers participate in the same vein. Should, ideally, reduce complexity and duplication of effort.

IF Gnome is accepting of all of this, of course.

And in that situation filing the bugs directly upstream is the most appropriate thing for end users because it will go to both groups (rpm maintainers and gnome) at the same time. It is simple, easy to understand, and avoids mistakes. At that point trying to force the triaging of bugs on the distribution level is just adding bureaucratic complexity for bureaucratic complexity's sake.

Or, stick to the policy?

Posted May 5, 2026 16:43 UTC (Tue) by cameron_herbst (guest, #183598) [Link] (1 responses)

I (co-)maintain around 30 packages on Fedora some of which are either included by default on some editions or are very popular.

The problem is not about gnome specifically — it just amplifies it due to the amount of users — but distributions in general. All the bugzillas and issue trackers just add friction. Upstreams never become aware of them and help debug them and package maintainers completely ignore them because they all maintain more than they can chew.

There should be tighter relationships with upstreams and more package maintainers so every package gets the attention it deserves.

Or, stick to the policy?

Posted May 5, 2026 19:08 UTC (Tue) by amacater (subscriber, #790) [Link]

My native bias as a Debian developer is showing here: Debian does a fair job at trying to cooperate with *all* upstreams. It's hard - as a volunteer-led distro with no links to a commercial upstream, the Debian developers and maintainers are busy enough with their own packages: team maintenance is helping here.

In many cases, the Debian folk *are* the upstream for particular packages - it works both ways here. Just demanding that a particular distro should work a certain way is fine if you're also volunteering to contribute time, effort and (perhaps) money and to work with others to make that happen.

Honestly aligning intentions with reality

Posted May 5, 2026 3:40 UTC (Tue) by raven667 (guest, #5198) [Link] (2 responses)

Something that's stuck in my head is how bug tracking and ticketing systems are a signifier of a commercial support relationship and aren't entirely appropriate for a community project, what's the SLA for tickets opened with a volunteer, and who do you escalate to? Triaging these bug reports _should_ be a full-time job, if there was someone paying for it, even someone from GNOME Foundation to collect reports from distros or something, but this situation isn't unique to GNOME or KDE and isn't resolved by pretending the relationship between user, packager, and upstream developer is something that it's not.

Users and promoters of distros and FOSS have all sorts of ideas of what an upstream and a distro do, or should do, but that doesn't always seem grounded in the actual reality of the amount of effort volunteer packagers and developers can actually do. Some packages are maintained by paid staff, by Redhat, other orgs or multi-vendor consortiums like Linux kernel itself, but it's not clear what any specific relationship is, when is the packager/developer a volunteer or a vendor, when are you a customer, a non-customer or a peer? It seems that a lot of people like cosplaying as a vendor when volunteering and putting FOSS in the world, but it obscures when it's appropriate to escalate or back off, or who if anyone is accountable for anything. It's not appropriate to bring "let me talk to your manager" energy to a volunteer, but it can be when the FOSS is supported by a commercial org and they are supporting it as part of a product, even if you aren't a direct customer.

Collecting all these bug reports like Pokemon, which represent some amount of work put in by Fedora users, but not having any real plan on what to do with them is kind of shitty to all involved, developers who might want those reports and users who might want those issues triaged and fixed. If the software is being provided "as-is" and there isn't really any accountability to fix issues, then why collect the reports at all, why waste peoples time? If the packagers or developers want to use some sort of bug tracking system for their own benefit, then don't open it to the public, doing so is a kind of implicit advertisement of support that may not actually exist. Good intentions are laudable, but sometimes one has to know their own limitations, and be firm, honest and forthcoming about what their capacity is to respond to issues, otherwise everyone involved gets stressed and frustrated, which is an avoidable consequence.

Honestly aligning intentions with reality

Posted May 5, 2026 9:03 UTC (Tue) by taladar (subscriber, #68407) [Link]

An issue tracker that is treated like a minimally moderated (just spam removal and such things) community forum for people experiencing the same bug to exchange information is still valuable.

Honestly aligning intentions with reality

Posted May 7, 2026 8:51 UTC (Thu) by nim-nim (subscriber, #34454) [Link]

It’s a pity no one in interested enough to try triaging the reports using AI instead of pointing users to yet another reporting tool.

Pointing users elsewhere is just a way to tell them to get lost because the people who don’t want to look at distro reports will definitely not want to look at the same reports in their own bug tracker. They love their own bug tracker because most users report distro-side so their own bug tracker is pleasantly empty.

The problem is not the users reporting at the wrong place. The problem is doing something with the reports.

What is the added value of a Linux distribution

Posted May 5, 2026 12:44 UTC (Tue) by ebassi (subscriber, #54855) [Link] (11 responses)

This is typical distro packagers tunnel vision: "we should send all bug reports upstream, what could possibly go wrong". Imagine if all downstreams did that, instead of just Fedora. Now imagine the people working upstream getting a ton of user reports from folks using different versions, different support strategies, different downstream build options, different downstream patches, and different downstream combinations of dependencies. All of this with zero triaging and resources coming from the very same downstreams.

For thirty years I have been sold the idea of downstream packagers adding value to the software I write or contribute to; as it turns out, it was just yet another unsustainable "line goes up" effort, and all that differentiation happening downstream is going to be adding more work on upstream projects already stretched pretty thin—and all of this while downstream packagers are actively complaining about various ecosystems trying to route around them.

What is the added value of a Linux distribution

Posted May 5, 2026 12:59 UTC (Tue) by pizza (subscriber, #46) [Link] (6 responses)

> all that differentiation happening downstream is going to be adding more work on upstream projects already stretched pretty thin

You know what will stretch that upstream project even thinner?

Maintaining an end-user-facing OS distribution of its own.

What is the added value of a Linux distribution

Posted May 5, 2026 13:44 UTC (Tue) by farnz (subscriber, #17727) [Link] (3 responses)

GNOME already maintains GNOME OS as a developer-facing distribution of its own; it would almost certainly be less work to make GNOME OS into an end-user-facing distribution of its own than to have a triage team that handles Ubuntu, Debian, Fedora, Gentoo and other variants on upstream GNOME packages.

What is the added value of a Linux distribution

Posted May 5, 2026 17:16 UTC (Tue) by hmh (subscriber, #3838) [Link] (2 responses)

That could well be true, but AFAIK (being a Debian Developer for nearly 30 years), neither Debian nor Ubuntu have a policy of "send bugs upstream" for *users*. It is, instead: "users file bugs with Debian/Ubuntu and the downstream Debian/Ubuntu maintainer will forward it upstream when appropriate"...

How well it works in practice is another matter entirely, and varies a lot.

What is the added value of a Linux distribution

Posted May 5, 2026 17:19 UTC (Tue) by farnz (subscriber, #17727) [Link] (1 responses)

That is also Fedora's policy - the reason this is a firestorm is that the GNOME package maintainers for Fedora are asking users to send bugs upstream, rather than triaging in the distro and forwarding upstream when appropriate.

The hard question is whether it's simpler for GNOME to have GNOME OS (and not care about bugs from other distros), to have the Fedora practical policy that's in dispute here (where downstream send their users upstream to file bugs), or to have the Fedora/Debian/Ubuntu paper policy (where maintainers triage bugs in the distro, and forward upstream if it's not a distro-caused bug).

I suspect GNOME will focus on GNOME OS

Posted May 5, 2026 18:41 UTC (Tue) by DemiMarie (subscriber, #164188) [Link]

I suspect that GNOME will focus on GNOME OS, and possibly support other downstreams whose GNOME integration is maintained by GNOME developers. This would leave third-party packages of GNOME software unsupported.

This is consistent with what I have seen from the GNOME project, but is NOT a criticism of the project. It's just the approach they have chosen to take.

KDE takes a very different approach and works much more closely with downstream distros, so long as those distros ship up-to-date KDE packages. In fact, my (potentially wrong) understanding is that KDE bugs in Fedora packages either should be sent upstream or are triaged by KDE developers. I forget which one.

I believe this is a philosophical difference. KDE is much more customizable, whereas GNOME focuses on having a single user experience that works everywhere.

What is the added value of a Linux distribution

Posted May 5, 2026 18:05 UTC (Tue) by hunger (subscriber, #36242) [Link] (1 responses)

A lot of projets due maintain a binary distribution channel formend users. What else are binaries in github releases, flatpaks, snaps, appimages, docker container, or just plain binaries in a tarball that developers maintain? The big projects now even started tonhave their own inhouse linux distributions.

The annoyance with distribution packagers is huge, otherwise no project would bother doing any of that. And rightfully so: Packagers up- or downgrade dependencies (sometimes even to versions documented to not work!), add random patches (some even taken frpm upstreams "rejected" pile), add random "features" (e.g. support for a horribly broken distribution theme), or just ship horribly outdated software (and then patch out user visible notes about a version being way out of date).

What is the added value of a Linux distribution

Posted May 6, 2026 7:46 UTC (Wed) by taladar (subscriber, #68407) [Link]

Lets be completely honest though, there are also plenty of upstream projects who just never update their vendored dependencies at all, don't care about security issues or critical bugs in those dependencies and have a "works on my machine" attitude towards any reported problem, no matter how much detail is provided. Here distro packager do a lot of valuable work to test and make the software work on a wider set of systems and without introducing critical vulnerabilities to the user's systems.

Projects only using packaging that includes all dependencies like Docker images, flatpaks,... are particularly prone to not caring about any vulnerabilities in anything included in that packaging too.

What is the added value of a Linux distribution

Posted May 5, 2026 15:10 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (2 responses)

I'm a Fedora packager and see the "please file upstream" in a different light. Kind of like "patches welcome". I'll at least do a cursory look to see if it is a Fedora-level problem first, but if it is an upstream, I encourage the reporter to go upstream directly. Because any further information request from upstream requires me to play messenger which is 1) no fun and 2) introduces more latency into the process. I'll Cc myself on the upstream issue so that I can backport a patch or spin a new release, but the Fedora-level issue stays open until *Fedora* has an update with the fix.

But I mostly maintain niche packages at the utility or TTY level, not many user-facing applications.

What is the added value of a Linux distribution

Posted May 5, 2026 18:55 UTC (Tue) by somlo (subscriber, #92421) [Link] (1 responses)

> I'll at least do a cursory look to see if it is a Fedora-level problem first, but if it is an upstream, I encourage the reporter to go upstream directly

I think this is the right answer. I am a packager (not a developer) of the upstream project. If the bug report is in any way related to the way the program interacts with the specific distro, then I feel I should attempt to deal with it myself, and propose patches & ask for upstream help as best as I can.

But if the problem being reported would happen regardless of whether the reporter used my distro, or any other distro, or even just compiled the program directly from source, then I'm likely to end up as a (weak) link in a game of telephones, so directing the reporter to take it up with upstream is completely fair, and in everyone's best interest, IMO...

What is the added value of a Linux distribution

Posted May 6, 2026 8:47 UTC (Wed) by farnz (subscriber, #17727) [Link]

Even when you upstream an issue, you still provide value - test builds of patches from upstream, for example, or context about what dependencies you built against that the reporter doesn't have.

Additionally, you're a good filter before it goes upstream - does it reproduce on your system? If not, why not?

Bumping dependencies with critical security vulnerabilities

Posted May 5, 2026 18:25 UTC (Tue) by DemiMarie (subscriber, #164188) [Link]

For quite a while, OBS Studio used a very insecure version of the Chromium Embedded Framework. The Fedora package updates that much more frequently.

The same goes with Qt, though the risk is lower. The only way I know to have an LTS version of Qt is to buy the paid version. Otherwise you need to update monthly to get security fixes.

Sometimes updates introduce bugs, but in those cases you have to choose between bugs or a risk of getting compromised. Distro maintainers I know tend to prefer the former.

The proper solution is to test with pre-release versions of dependencies, and either fix any regressions upstream or work around them. This ensures that one can update to the next release without problems. However, I’m not aware of widely used projects that do this.