Hug Days have been frequent lately (8 already this year!). However, instead of the previous general Hug Days, these usually come with a specialty. Some particular package or area is picked to be looked at for the day. This is a great idea and I think it should be much more effective than attacking bugs at random. However, often the category ends up being Gnome specific (5 of the aforementioned 8 have been). No problem with that, but derivatives should participate in these types of events as well. I’ve gotten the impression that while there are people doing hard QA work on their own, or when someone asks to test something, these organized events are often ignored by Kubuntu people (please correct me if you’ve been participating!) (how about Xubuntu and others?) If the gnome testers are spending a day looking through desktop bugs, then KDE/xfce/etc users/testers can spend their day looking at packages related to their respective desktop.
What’s missing are the resources that the bug squad guys and other teams have set up and set up for each hug day to help manage and improve the bug reports. Namely:
- A list of bugs to be worked on for the Hug Day. Here’s the one for Gnome Power Manager for Hug Day on Feb. 21 (that’s today in some time zones!). Here’s an analogous page for KDE Guidance Power Manager so this time Kubuntu folks can participate. I don’t know if other derivatives use a different power applet, but if so, then it would be appropriate to make a similar page for it for this Hug Day. And so on for future bug hunting events.
- Debugging procedures. There are pages there for many parts of GNOME on how to improve bug reports and none for KDE or other desktops (if you know of some pages and they just aren’t linked there (or anywhere) please add them!). This certainly needs some work to make bug management effective. To start building up the resources, maybe next time you work on a bug, add a wiki page for that component to tell others what sort of information was required. Combined with 5-a-Day, that should get some decent resources up pretty fast to make the process more efficient in the future.
That’s just a start to some more organized QA for Kubuntu, which I think would help a lot in getting it as polished as Ubuntu is.