Backing off from FlySpray

You might remember, or not, that I spent most of November deciding and working on putting online a new bug tracker for the xine project.

This was due to my (and not just my) dislike of the SourceForge bug and feature request tracker, and to the fact that Siggi, the current maintainer of xinehw.de, is not always around to fix stuff on the spot.

Today, when I checked the traker for a new bug was reported, I seen there was announcement of a new version. So I tried to put that online, and to my dismay, the new version fails to work with PostgreSQL in a lot of places. On the bug linked in the download page, the author (I suppose) says that he’s not proactively working on the PostgreSQl support, and that any further bug will have to be fixed by the community.

As I don’t want a bug tracker I have to maintain codebase-wise, too, I decided to give up on using FlySpray. The alternative would be to use MySQL for FlySpray, but as the bug tracker shares the virtual server with this blog, and this blog uses PostgreSQL, I’d rather avoid trying to run two different DBMS on it.

So while I was open to alternative, Lua suggested me to try Bugzilla; he said that the recent versions are easier to set up, and he’s certainly right when he says that the amount of traffic that Gentoo’s bugzilla gets is tenfold times what xine’s ever will (considering that there are just a few bugs reported in the one month that the new tracker has been up, one being my own.

Since version 2.20 (current is 3), Bugzilla supports PostgreSQL properly; considering Bugzilla is backed by the Mozilla Foundation, and that they do provide commercial support for those who are willing to pay, this means that pgsql support most likely will be there for as long as I need, rather than just for a couple of versions before breaking.

Also, Perl CGI is probably faster than PHP, considering that Flyspray is the only PHP thing that runs on the server. Too bad that bugzilla does not provide a FastCGI interface or that would have been probably nicer too.

All in all, Bugzilla does have quite some good points to his favor: it’s a widely used application, well tested, and well known by many users; it’s being developed since years, and it’s probably going to continue being developed for the years to come; it comes in a nice ebuild with all the Perl dependencies satisfied, which makes it quite easier to handle, one of the biggest pain in the ass for Bugzilla is to install and maintain all the Perl dependency packages, thanks to Gentoo it’s gone. Also, Bugzilla is well supported by external software (Malone for Ubuntu, a lot of non-web reporter applications, IRC bots, included my own ServoFlame), and version 3 also seems to have some kind of Web Service interface, which I will probably dig into.

Sure there are things in Bugzilla that I find a big awkward: the HTML interface is so strangely ‘90s, considering it has a browser project behind. Flyspray on the other hand had a nicer look; while I didn’t like the line that appears at the bottom when you apply the changes, with the common smily emoticon which makes it so much forumsy. FlySpray’s home page, with the list of open bugs is certainly more useful than the default Bugzilla homepage, and while certainly Bugzilla’s interface not using a lot of JavaScript is more accessible, FlySpray has a more userfriendly one.

So I prepared the binpkgs (for what they do matter, as most of those were perl stuff), for bugzilla and dependencies, uploaded it to the server, and installed it. It’s currently setup on a shadow vhost; tomorrow I’ll see to make it appear more decent, by putting the xine logo above, changing the colour scheme around so that it uses xine’s colors and so on. If I’m able to do that, it wouldn’t look as ‘90s as it looks now.

There are a few points I still have to clear; to begin with I would like to send a mail of all new bugs and comments and changes to the xine-bugs mailing list as the SourceForge trackers did.

Then there is another problem: Bugzilla requires an account to get the new bugs assigned to for the various components. This is the kind of account bug wranglers in Gentoo have. As it is, we need a default account used by the developers to get the new bugs listed; using xine-bugs would work, if it wasn’t that I don’t really want whoever comes around to just get a new password for the account and do whatever they want with the bugs.

Unfortunately, the registrar used for xine-project.org (Register4Less) does not seem to allow an alias for multiple addresses, which makes it impossible to use a multiple alias as are used on Gentoo. I suppose the easy way around this is to actually set up a full-fledged server on xine-project.org, to receive the mail and handle aliases, then add a procmail rule so that all the mail received by, for instance, xine-bugs at the server is redirected to the xine-bugs mailing list on SourceForge, with the exception of Bugzilla registration and password handling, which would go to the postmaster (that is me at the moment).

I suppose I should start bothering a bit our dear Robin and Ned, in the next days 😉 From Ned I’d like to know how the new bugs report on channels is implemented to see if I can add something more to ServoFlame.

So in the next days you might see me spending less time on xine to fix ServoFlame’s bugzilla plugin, and implement a couple other things. And of course I’ll be playing Command & Conquer 3, which I skipped over the last two days because of family stuff.