Why you use trackers rather than multi-assigned bugs

Today seems to be the day of multi-assigned bugs, so I decided to write a few words on why you should not file a multi-assigned bug but rather file a tracker and then multiple bugs, which is what I do for the issues I found with tinderbox (and not just that) and the way I reached over 1500 bugs open at one point.

While creating new bugs means that you got more work to do, and even the bugzilla database gets loaded more, mutli-assigning a bug (that is creating a bug with a list of ebuilds involved and CCing all the maintainers of those ebuilds) means overloading the mail server and even worse the mailboxes of the developers involved. For each comment (useless or not) you get to send multiple emails, and it’s not extremely unlikely that a dev gets to receive multiple copies of the same comment if he’s on many aliases.

Even more obnoxious is when you get in a fight on whether that’s the correct way to proceed for one given package, and you get to have back and forth arguments between the filer (or the QA team, or whoever) and the maintainer of that package that get sent to multiple developers who are not involved and who are most likely not interested in the problem. Even worse, you have no clear timeline on when a bug was corrected for a given package, since the history is merged and you got to check on when someone commented, and de-CCed an alias from the bug.

The tracker method allows for the tracker to be visible by the QA team, which can monitor which bugs get fixed and which gets ignored, and each team only gets to see what they have to be concerned with. And to file the actual bugs, you can just use the ”Save as bookmarkable template” method that I also use to file my bugs.

So please use trackers and templated-bugs, I beg you!

Why I like my bugs open

Even though I did read Donnie’s posts with his proposal on how to better Gentoo, I don’t really want to discuss them at the moment, since I have to admit that Gentoo politics is far from what I want to care right now, I have little time lately and that little time should not be wasted in discussing non-technical stuff, in my opinion, since what I’m best doing is technical stuff. Yet, I wanted to at least discuss one problem I see with most non-technical ideas about how to improve Gentoo: the bug count idea.

Somehow, it seems like management-kind people like to use the bug count of something as a metric to decide whether it’s good or not. I disagree with this ferociously because it really does not say much about software, if we consider as closed bugs that have just been temporarily worked around. It would be like considering the count of lines of code as a metric to evaluate the value of software. Any half-decent software engineer know that the amount of lines of code alone is pointless, and that you should really consider the language (it really changes a lot if the lines can contain one or twenty instructions each), and the comment-to-code ratio.

If the Gentoo developers were evaluted based on how many open bugs there are or on the average time a bug is kept open, we’ll end up with an huge amount of bugs closed for “need info” or “invalid” or “works for me” (which has a vague “you suck” idea), and of course “later” which is one kind of resolution I really loathe. The problem is that sometimes, to reduce the impact of a bug on users, you should put a quick workaround, like a -j1 in the emake call, or you’ll have to wait for something else to happen (for instance you might need to use built_with_use checks until the Portage version that supports EAPI 2 is stable.

Here the problem is that the standard workflow used in Bugzilla does not suite the way Gentoo works at all. And not everybody in Gentoo follows the same policy when it comes to bugs. For instance, many people would find that any problem with the upstream code does not concern Gentoo, others feel like crashes and similar problems should be taken care of, but improvements and other requests should be sent upstream. Some people think that parallel make is a priority (I’m one of them) but others don’t care. All in all, before we decide to measure the performance of developers based on bugs, we should first come over with a strict policy on how bugs are handled.

But still, open bugs mean that we know there are problems, and might or might not mean that we’re actively working on solving them, it might well be that we’re waiting for someone else to take care of them for instance. How should we deal with this?

I sincerely think that we should see to add more states to the bugs state machine. For instance we could make so that there’s a “worked around” state, which would be used for stuff like parallel make being disabled, --as-needed turned off and similar. It would mean that the bug is still there and should be resolved, but in the mean time users shouldn’t be hitting it any longer. Furthermore, we should have a way to take a bug off our radars for a while by setting it “on hold” till another bug is solved. For instance, the new Portage goes stable so we can deal with all the bugs related to EAPI 2 features being needed.

Then we should make sure that bugs that are properly resolved, and confirmed so, are closed, so that we can be sure that they won’t come up again. Of course it can’t be the same person who has marked the bug as resolved to mark it as closed, but someone else, in the same team, or the user reporting the bug, should be able to confirm that the resolution is correct and the bug is definitely closed.

But the most important thing for me is to take away the idea that bugs are a way to measure how software sucks and consider them instead a documentation of what has yet to be done. This is probably why trackers different from Bugzilla often change the name of the entries to “tasks” or “issues”; language has a high psychological impact, and we might want to deal with that ourselves.

So, how many tasks have you completed today?

Migrating documentation

Today’s plans of working were messed up, as I’m waiting for a friend of mine in about an hour, so I dedicated the first half of the afternoon at fixing up the repositories for ruby-hunspell and rust, as I wrote yesterday.

I also ended up adding a few more projects of mine to Ohloh as it helps me tracking down of stuff I’ve been doing and I left behind.

Then talking with a friend of mine (hi Alberto), I remembered that there were USE flags in xine-lib that are non obvious, and I shold have document them already. I asked drac for permission, and now xine-lib’s metadata.xml has documentation for real, win32codecs, mad, flac, gtk, imagemagick, gnome, mmap and truetype USE flags. It should cover all the non-obvious ones.

Checking xine-ui too, after fixing one of the bugs that were reported to xine’s bug tracker after I closed them on Gentoo’s bugzilla as UPSTREAM, I also found that there was a very old copy of xine-ui still hanging around in portage. Thanks to drac, that’s gone, as well as the ncurses USE flag on xine-ui that was unused anyway (now the code in configure is gone from CVS too). And if you use xine-ui from CVS you’ll now get a datafile for shared-mime-info for tox playlist files, thanks to Peter Fox.

I also took care of updating the xine’s maintainer guide removing some outdated and now pointless information, and providing the tracker as main submission entrypoint, rather than xine-devel. There was a lot of stuff to update, as the guide was not updated for exactly 11 months (last change being 30 January, before I left from Gentoo).

Now I’m mostly tempted to document a few more things on xine-ui’s flags, and add some IUSE defaults to xine-lib so that users gets some sane defaults (like enabling a52, dts and mad decoders, and disabling mmap and truetype).

So basically today is a day of migrating documentation so that it follows the current ebuilds, and adding proper flag documentation to metadata rather than relegating it around the maintainer’s guides, at least user side. Expect more commits from me just to add documentation :)

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….

Happy birthday to me, sorta.

So today is my birthday. And beside a little downtime of the vserver, stuff is going almost decently. Tomorrow I have another power outage (five hours, yes FIVE hours of power outage; gotta love ENEL).

Anyway, now that the vserver is reachable again, I wish the announce the testing of the new xine bug tracker (which is hosted on this very same vserver ;) ). Thanks again to Jon who suggested Flyspray to me, as that’s the software we’ll likely be using (unless the rest of xine developers are against it).

Please note that the Jabber notification is not yet enabled, but I hope to add support for it soon.

So this is my birthday present for what concerns xine, hope it will be useful to others, too :)

The long story of xine and the bugs

You may remember some time ago I blogged about the need for the xine project to replace the SourceForge bug tracker with something more usable.

Today I felt like this need is even more important, when a change in last.fm servers (or rather in their HTTP response) caused xine 1.1.8 not reporting anymore to Amarok the changed last.fm track.

The problem here was that the bug in bugs.kde.org was handled directly without submitting anything up the stream (I suppose I was unavailable at the time). I’m not surprised, Everybody in the Amarok team seems to agree that the SoruceForge tracker is unusable.

But, if you are one of the people who ever looked for alternative bug trackers, you might know that it’s not an easy task: the most common choice for big projects is Bugzilla, but the resources it needs makes it impossible to find a cheap host for it. The alternatives aren’t that better: Mantis is, in my opinion, just as bad as SourceForge tracker, Roundup requires mod_python, and the other tracker I know is Scarab which is JSP-based.

Now, I asked before the incidents of last summer to Siggi (the xinehq.de admin) if he could provide a tracker, and he agreed to try putting Roundup on it, but he hasn’t wrote anything to xine-devel in the mean time, so I asked him to bring me up to date with the status, but I’m afraid it’s not going to be feasible in short term, at this point.

Of the two alternatives, Roundup is probably the simplest to host as it requires Apache, mod_python and a database, but it has the disadvantage to require a complex configuration, as it’s more like a framework for bug trackers rather than a bugtracker of its own. Although most of the work has already been done by Luca for MPlayer and FFmpeg, and I can ask him to pass on his configuration, it’s still a bit of a mess to configure for what I saw.

Scarab on the other hand has higher requirements, as it’s a JSP webapplication, but it seems to be more ready for consumption out of the box. The problem here is to find a proper hosting provider: JSP hosting is expensive, very expensive sometimes, and the alternative is a dedicated or virtual server, which also isn’t cheap (although it might be cheaper than the hosting).

Now, of course I’ll have to wait for Siggi, as he might have good news for me, and then I won’t have to worry about it anymore, but in the mean time, I was wondering which option we have if he doesn’t have good news.

A basic JSP hosting, without PostgreSQL nor SSL support, seems to be about $25 a month; with the current dollar value, it wouldn’t be much at all, if I had a stable job, but I don’t have one, plus it might be desirable to get SSL support so that the passwords aren’t sent in clear text (the SSL support is available together with PgSQL and other services at twice the price where I looked up to now). If there was more interested in xine project by its users (a lot of which are Amarok users who use xine as a backend) it could be possible to try a yearly fundraiser to get the needed money, but considering that I rarely see comments in my blog about xine, I doubt doing so would bring us the needed money every year.