Re: Improve handling of bug reports for GTK+?

[Matthias Clasen <matthias clasen gmail com>]

On Fri, Aug 10, 2012 at 2:29 PM, Andre Klapper <ak-47 gmx net> wrote:
> [Please CC me on answers as I am not subscribed ot this list.]
>
> The situation of GTK+ in bugzilla.gnome.org:
> High number of open tickets, high number of unreviewed patches,
> constantly growing number of tickets, no real triaging of reports.
>
> Feedback, please: I'd like to know how you (GTK+ developers/maintainers)
> handle GTK+ bugmail and work in Bugzilla.
> Do you read gtk+ bugmail at all? Does it scale? Is it too noisy?
>
> A first proposal (please tell me if it makes sense):
> https://bugzilla.gnome.org/describecomponents.cgi?product=gtk%2B lists
> for most components the default assignee "gtk-bugs gtk org".
> In case you are only interested in following specific areas of the GTK+
> codebase (is that the case?), would it make sense to have one default
> assignees per one component (for example introducing
> gtk-gtkapplication-maint gnome bugs for GtkApplication, and likewise)?
>
> Are there components missing? Which ones? It feels like lots of stuff is
> dumped under "general" that does not find a better home because there
> are no Bugzilla components for some of the newer widgets.
>
> So, how would Bugzilla work better for you?
> (I'd also happy to discuss this in a GTK+ meeting, but
> https://live.gnome.org/GTK+/Meetings lists the next meeting for 15
> months ago.)

Hi Andre,

sorry for not replying earlier.
I'm currently taking time maybe once a week to look at some GTK+ bugs.
Sometimes that results in a bug fix, or marking a few bugs as
duplicates. Sometimes, I just add comments. My main way of doing this
is to just look at the new and changed bugs for the last few days.
It is pretty rare that I look at old bugs, unless I'm looking for a
bug to duplicate something to.

What is clear is that nobody else is paying more attention either, and
we are clearly not able to keep up with the bug inflow, let alone the
backlog.

I don't think more components will really make things much better. A
unstructured list of bugs becomes a blur to me beyond maybe 30 or 40
bugs. If we were to create enough components to keep each below 40
bugs, the list of components would grow so large as to be
unmanageable, and we would spend all of our precious little bugzilla
time moving bugs to the right components to keep things balanced.

Historically, we have been very reluctant to close bugs just because
they are old. I think we should probably revisit that policy. As an
example, there's some 50 bugs about gtk2 era xinput. The device
handling has been completely rewritten and rebased on xi2 in the
meantime - some of the bugs may still apply, but nobody has the time
(and very few people, not including me) have the hardware to re-verify
them.

Of course, leaving patches unreviewed is much worse than unanswered
bug reports, and we should try to improve our patch review. I don't
have any great answer for how to do that, though.