Package Maintainer Responsiblities vs. unmonitored Bugzilla components for GNOME packages

[ngompa (Neal Gompa)]

@carlwgeorge

In my packages, if I get a Fedora bug report for something I know is an upstream issue, I’ll link it in the Fedora bug and close it with the UPSTREAM resolution. If I can’t find an existing upstream issue, I’ll encourage the reporter to file one or file it myself. I consider that a normal part of bug triage, and think most packagers (not just in Fedora but in many distros) feel the same way.

This is also how I operate too. That said, I do have a large pile of bugs too, and I try to dedicate some time to evaluating them. I also actively re-evaluate bugs every time I ship an update for a package (it’s very easy when Bodhi gives you a list in the web form). I imagine most packagers attempt to operate somewhat like this.

@dalto

One fundamental problem is that many reporters don’t know how to differentiate between packaging problems and upstream issues. It seems like it is also wrong to send them all upstream and make them triage Fedora issues.

A great number of upstreams would be very angry if users were sent to them to report bugs for packages as a default. And in general, the job of a Fedora package maintainer is to identify, curate, and work with upstream. That can also mean forwarding bugs on your own, or requesting the submitter to do so.

@decathorpe

But I don’ think the auto-responder has actually helped at all. Bugs are still being filed - likely at least in part because there’s no indication that you’re filing a bug against a component where you’ll just get a “go away” auto-response. Additionally, once the form is filled and submitted, people likely feel like their “work” is already done, and then they’re asked to go do all that again somewhere else.

The auto-response text also explicitly says that downstream / packaging bugs and / or bugs for release tracking purposes should remain open, but also

Bug reports for this component on Red Hat Bugzilla are not actively monitored

which sounds like a “have your cake and eat it too” situation. If valid downstream / packaging bugs should remain open, then bugs for these components also must be monitored, otherwise keeping these kinds of bugs open is just pointless.

As a point of comparison, Fedora KDE has not requested a similar setup despite also having a very heavy bug reporting load with many components delivered to users. We do look over the bug reports periodically and I do use the information to identify trends. It has actually been pretty handy when I need to have conversations with upstream about larger issues.

We are, however, quite bad at tagging bug reports to be closed when we ship KDE stack updates. I have not yet figured out how we can improve this aspect, but it is something that we should eventually tackle.

I personally do not think it’s a good idea for any Fedora contributor to be ignoring our central bug tracker system, nor is it a good idea to convey that bug reports are 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.