|
|
Log in / Subscribe / Register

Or, stick to the policy?

Or, stick to the policy?

Posted May 4, 2026 22:23 UTC (Mon) by Karellen (subscriber, #67644)
Parent article: Bug-monitoring expectations and Fedora GNOME packages

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?


to post comments

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.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds