Re: Improve handling of bug reports for GTK+?



On Fri, Aug 10, 2012 at 8: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?

Not a GTK+ maintainer, but I maintain other modules, so my 2 cents here:

One thing I miss is a centralized page where I can see all the
outstanding patches up for review in the modules I maintain. Something
similar can be constructed manually with a query (like this?
https://bugzilla.gnome.org/page.cgi?id=patchreport.html&product=gtk%2B),
but there are many simple improvements that would make it even more
useful:

- Ability to sort by age. The older a patch is, the worse it is that
you ignore it. I guess up to a certain threshold where the submitter
won't care anymore, but still.
- Sort by size. Reviewing a small patch can be done easily and much
more frequently. Reviewing a 50k patch probbaly requires sitting down
for a long time.
- Sort by activity/interaction? If I have already looked at a patch
once and this is a second/third/etc iteration, tell me. Probably only
doable if we are strict about "one-patch-per-bug", but I think this
would also be useful.

We could do many things here, but you get the idea. I think having
something like this for each bugzilla account for the modules the
person maintains (or maybe just the modules she chooses to track)
would help a lot.

Xan


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]