On Fri, Aug 10, 2012 at 2:29 PM, Andre Klapper <ak...@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-b...@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-ma...@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. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
