The curse of a good bug reporting system

A good bug reporting system, by being good, can make a project look bad.

In five-or-so years on SourceForge, xmlroff garnered 24 bug reports. In the couple of months since moving everything to, xmlroff has already amassed over 60 Trac tickets.

It may look as if xmlroff is suddenly much buggier, but it’s due to finally having a bug reporting system that’s easy to use.

Because it’s easier to use, we use it more. There’s been tickets for moving to and for pie-in-the-sky ideas like a Texinfo-XML-to-FO stylesheet as well as for common or garden bugs. Since it’s also easy to link to bug reports, there’s now more ticket numbers in the notes on test results and in commit messages.

The proliferating tickets and ticket references point to quality improving, not worsening. After all, we’ve also closed more tickets than xmlroff had bug reports while on SourceForge.

First xslide update in years

I recently checked into CVS the addition of a sub-menu for locating xsl:function elements. It is, as the title notes, the first update of the xslide XSL mode for Emacs in literally years.

xslide itself may be a dead end since its based on neither nXML nor Semantic, so it doesn’t quite work the same as the other modes that people use (nor does it matter that it predates nXML). I still use xslide (which is why I updated it), and I even copied it to make an Emacs mode for Ant build files, but it would be more useful if it could indicate when the XSLT stylesheet is not well-formed. Then again, perhaps that problem could be solved with Flymake mode and an XML parser.