regular bug triaging
jani.monoses at gmail.com
Thu Dec 14 14:50:14 UTC 2006
as Xubuntu bugs reports keep coming in we do not always have a timely
response to them and their number keeps growing. This is expected as the
user base is growing as well.
So far we have been more or less regularly attending to them as they
came in, with no planned Bug Days or equivalent events, but with a
notable peak a few weeks ago when Cody swept through a lot of them.
I propose having at least one, but preferably more people who volunteer
to regularly keep up with the flow of incoming reports and take care of
the interactions with Xfce bugzilla and the rest of Ubuntu Bugs.
The interested person(s) should have Xfce bugzilla accounts and be able
to devote ~2 hours a week to this activity. With 2-3 people and the
current amount of bugs I think it is doable.
An essential aspect is dividing the task is many small, well defined and
disjoint ones so that a significant progress can be seen even with 10
minutes work. Division can be done according to various criteria, here
are a few ways to 'tag' the bugs, but I am sure we'll come up with more
and in time converge on a scheme which is both effective and fun to work
* Division based on packages:
- panel plugins. The one responsible will exclusively look after bugs
reported on packages named like xfce4-XXXX-plugin. It involves seeing
what the status of the bug is at the xfce goodies upstream project and
in debian. There's an upstream Xfce deveoper who is interested in
hearing about our patches and feedback.
- thunar, xfdesktop: they get the most reports so one could well occupy
one triager full time. Again it means having good communication with
upstream bugzilla, like searching whether it's a known bug, filing it
upstream if not, and in both cases linking from LP to the bugzilla entry.
- non-xfce apps: both gnumeric and abiwird have a lot of bug reports.
They are used by Gnome users as well of course and they are handled by
other ubunteros but they sure can use some help, as Xubuntu is the main
user of those packages still.
* Based on time-slotting:
for timely responses people could pick a day of the week when they know
they can contribute time regularly.
* Making sure report is assigned correctly:
a person would make sure the bug actually mentions the correct package
(of course when it's possible to tell and obvious). There are quite a
few bugs filed against xubuntu-meta or xfce4 because the user cannot
identify the exact culprit or does not know what package handles what
fucntionality (which users should not know or care about really, but it
helps in reports). Similarly bugs which are kernel/network/base system
bugs are often reported since the user has Xubuntu installed and does
not know it probably happens in Ubuntu as well. Also in this category is
checking if the bug affects Ubuntu/GNOME for packages we share and those
which are related (evince/evince-gtk, gnome/xubuntu-system-tools)
Of course all these still mean trying to reproduce the bug, asking for
details, just like we have been doing so far, but in a more organized
and hence predictable fashion.
Then we can also have small planned gatherings on IRC to clear up issues
that may come up and get a review of the process and discuss
improvements. Also a weekly report by one of the bug triagers to the
list summarizing the most recent happenings would be great as well.
More information about the xubuntu-devel