Package Maintainer Responsiblities vs. unmonitored Bugzilla components for GNOME packages

Bugzilla supports templates, we used them before we started using the guided form thing. That’s not really an excuse since we could use it for this purpose too.

Debian’s maybe, but that’s because the ergonomics of that tracker is so bad that even GNU (who created it) doesn’t use it anymore. My experience with Launchpad for Ubuntu is that they are actually fairly attentive, even if they are slow to act on anything (I spent nearly a decade working at a company who ran Ubuntu in production and had to deal with it fairly significantly, so I’ve got decent experience with interacting with Ubuntu).

I’m not so sure that’s the case. That said, software bugs matter to us too, because as an integration project we have to figure out what to do with these things. That’s why we track software bugs in our Fedora release development process.

And the thing is, telling people to go to GNOME GitLab (or in the KDE case, KDE Bugzilla) is a bad path in the first place because there is no 1:1 mapping to how we maintain and track a component and how upstream does. You’re also telling users to deal with people who may or may not have any real influence on how soon a fix reaches them. It’s perfectly reasonable after some triage work to push it upstream, and that’s what we as maintainers are expected to do.

Telling everyone to go to the GNOME GitLab by default doesn’t help us because then we at the Fedora level know nothing and we can’t do prioritized backports/cherry-picks, etc.

GNOME’s lifecycles, priorities, etc. are not the same as ours, and defaulting to telling them to go there makes them think we have no agency of our own to support our users.

While it’s kind of off-topic, I am not a fan of moving from Bugzilla to a forge based tracker for exactly this reason. As someone with a lot of packages, Bugzilla’s advanced structured data model and querying capabilities are the only reason I’m able to keep track of anything at all.