regular bug triaging

Adam Miller maxamillion at
Thu Dec 14 16:09:33 UTC 2006

I'm in. I should undoubtedly be able to devote 2 hours a week to this. But
let me double check for mental clarity, I would just be cross referencing
bugs filed on launchpad with ones on xfce's bug tracker and documenting if
so and if not, stating that as well?


On 12/14/06, Jani Monoses <jani.monoses at> wrote:
> Hello,
> as Xubuntu bugs reports[1] 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
> with:
> * 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.
> thoughts? volunteers?
> thanks
> Jani
> [1]
> --
> xubuntu-devel mailing list
> xubuntu-devel at

--OpenPGP key: 5DBFA065--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the xubuntu-devel mailing list