Thinking nice of bugzilla again (and some rbot news)

Bugzilla always gave me the idea of something slow, heavy, and an absolute waste of resources.

I start to think better of it. While certainly it will kill easily a server when used with big projects like Gentoo or KDE, it seems to be quite decent for a small project like xine on a small vserver.

The other reason why I thought badly of Bugzilla was the amount of perl modules one had to install to get it to work; luckily this problem is gone thanks to Portage, that takes care of everything for me (or almost everything).

The final reason why I thought Bugzilla was not feasible is the interface. God knows the default interface of Bugzilla is horrible. it’s strange considering the the developers are Mozilla related, and it’s also strange that it uses so many tables around for the same reason. I thought tables for non-tabular data were quite out of standard nowadays, I don’t even use them myself when I’m paid to make a site!

Anyway, the template engine used by Bugzilla is quite impressive, and it can be used to actually get Bugzilla a decent interface. There are also some new skins available around that gives it a very interesting effect, although I haven’t used any of those yet. For now I stopped at cleaning up the interface a bit, removing the redundant actions listed at the bottom (they are the same as listed at the top), moving the logout action to the right of the screen like in other webapps, and so the search box.

I also removed a lot of information and links on the index, mostly redundant stuff or stuff like the infamous sidebar, that I never seen anyone using. It’s lot as clean as GNOME’s bugzilla, nor as shiny, but it’s not bad either. I hope to actually improve it in the future too. What I’d really like is to show the most recent reported bugs on the homepage, so that users would see more easily what might be their problem (if it’s a problem that came up recently like the infamous build failure of the internal libcdio copy with the new linux-headers).

Anyway tonight I switched the xine bug tracker to Bugzilla, importing by hand the open bugs from Flyspray (tomorrow I’ll import the closed ones too). I’d like to make the interface more shiny with some icons, but I don’t know which icons would look good with the icy look of the current skin (which is derived from the xine logo and the xine site).

I hope that mailing works, it’s the first time I set up procmail, and I’m not sure if it works properly because I see some errors in the mail queue, connection failures to the mail relay (which is internal to the farm where the vserver is located). Tomorrow I’ll see if it’s easier to just get it to send the mails directly.

If you read about my problem of having data filtered so that the password change requests don’t leak on the mailing list, the solution was quite easy, with procmail and a xine-project user (which is where flyspray was installed, so it existed already).

Also, thanks to the fact that bugzilla is, well, bugzilla, now ServoFlame on Freenode will answer to requests about the xine’s tracker too.

Talking about ServoFlame, today I also worked a bit on its bugzilla plugin, now it uses httpclient, rather than http-access2 (httpclient is the new name of http-access2; I also asked for marking httpclient stable today), and reuses the client instances for the same bugzilla, I haven’t checked if that means that it uses permanent connections yet, but I’d sincerely hope so, as that should improve multiple requests to the same bugzilla, especially for those trckers using SSL (like FreeDesktop). You may now use ServoFlame in all the channels where it’s present to request bugs about the listed projects, to know the listed projects, just ask him to “zilla list”. I finally implemented proper authorization support so that zilla list is available to anybody, but just I can add or remove trackers to the list.

For what concerns the generic rbot live ebuild (which stays where it is because upstream is now suggesting not to use rbot 0.9.10, the last release), I added an nls USE flag the other day, but now I force ruby-gettext on everybody; this is mostly because I want the gem to be generated as much as possible identical to the one that’s going to be released, which means that the locale files needs to be there; anyway it’s not a runtime dependency, you only need to install it to install rbot then it can go.

I also added a dict USE flag; this flag controls the dictclient plugin, a client for the RFC 2229 protocol (that is, dict), that uses the ruby-dict extension. As it needs the dependency or it fails to load, leaving it enabled by default wasn’t really a good idea in my opinion; now if the USE flag is disabled, the plugin is also disabled (by default, you might enable it manually, but then rebuilding with the USE flag enabled takes less hassle); as ruby-dict was not in portage, I added it, this makes it the third package added to portage just to get rbot plugins working (the other two were dev-ruby/tzinfo, for the time plugin, and dev-ruby/shorten for the shorturl plugin).

Unfortunately i already have disabled almost all the rbot’s plugin on my ServoFlame so I don’t see the failure to load most of the plugins when the extensions they need are not found. Tomorrow I’ll see to get an install of rbot on my workstation and with all the plugins enabled I’ll see what does not run correctly.

Okay now it’s very much late, and I should be sleeping already….