Re: Improve handling of bug reports for GTK+?

[Tristan Van Berkom <tvb gnome org>]

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.

The important thing here is to have a high quality list of components I think.

Perhaps the GTK+ bugmail is not as high traffic as I expect it might be, but
personally I already receive all the bugmail for Glade and I also receive any
bugmail in GTK+ bugzilla regarding the GtkBuilder component.

When I was working on height-for-width support, we created the "EL"
(extended layout) whiteboard keyword for triaging... this is awkward
because one needs to perform explicit searches to get the EL bugs.

So, while I was working on the geometry management, I did lookup
those bugs on a regular basis... however since then I do not receive
any notifications regarding GTK+ geometry management issues.

If we can have at least a geometry management component,
which would be the appropriate place to submit patches/bugs
related to size requests and allocations done by various widgets,
then I would be happy to subscribe to those bugs as well and
it would be no trouble for me to review those patches as they
come in.

Perhaps GtkApplication would also be a good component, not
sure, however I think we want to define the components in such
a way that they are "domains of issues" and not particularly
code bases (the GtkTextView is a good exception since it is
really complex and separated from the rest of GTK+, the same
goes for GtkTreeView/GtkCellArea, which should probably
be in the same bug domain).

Also iirc, subscribing to bugmail is done in an obscure fashion,
it might help to have some additional support in bugzilla for that
(perhaps a list of check boxes to select the components which
one is watching in a given product... with a real user interface,
without having to understand that one needs to "watch the
activity of a virtual user who is assigned as the maintainer of a
given component", the current way is only really discoverable
over longer term interaction with other GNOME folks either by
irc or mailing lists (i.e. you have to be told that it's possible
before you can even subscribe to bugmail).

I also think that having more people easily subscribe to
bugmail is good for the project; I try to encourage any
of Glade's newer contributors to subscribe to the relatively
low traffic bugmail, I think it helps to give contributors a sense
of what's going on, a greater sense of responsibility and
a stronger feeling of being a part of something great.

My 2 cents,

Best,
    -Tristan

>
> 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.)
>
> andre
> --
> mailto:ak-47 gmx net | failed
> http://blogs.gnome.org/aklapper
>
>
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list