blogs and bug tracking

I believe that adding blogging technology to bug tracking systems (such as the Debian BTS and the Red Hat Bugzilla) offers significant benefits for users and developers.

It seems that there is only one significant difference between the features offered by blog software and the features required by bug trackers, blog entries are owned by the person making the post (the owner of the blog) and BTS entries are owned by the package owner. This is a minor technical difference, adding the ability for anonymous users (or users who have authenticated via an email address or other method) to create new entries in a blog owned by someone else is a minor feature change. Once the entry is created only comments would be accepted, and comments could be made in the usual manner with moderation etc.

The benefits of using blogging software (or extending current BTS systems) would be to have RSS feeds of bug reports and comments on bugs, include a single feed of all bug reports (IE blog entries) and updates (IE comments on blog entries) for a single blog (IE package) - this functionality doesn't seem to be common in blog software but surely will be soon.

This would allow Planets of recent bug reports in distributions or in areas. EG a SE Linux planet installation could syndicate the bug feeds for packages in Fedora and Debian as well as other sources of SE Linux information. The SE Linux bug feeds could include all bugs with the selinux tag in all blogs on the BTS, thus a single Planet configuration could easily cover all new development and debugging.

Another configuration possibility would be to have a single blog for all bugs in a distribution and to have tags for each package, this would become messy though as tags have to be used for issues that are not specific to packages (EG a "selinux" tag would list bugs in all packages that relate to SE Linux).

Tags could be changed by any user (possibly with some restrictions), and there could be special tags for release-critical bugs or for bugs in different stages of QA (for example the Red Hat Enterprise Linux approval process could be managed by adding certain restricted tags to the bug - this would also allow getting a feed of all bugs that have passed certain approval milestones). This would make it easy to get a list of all bugs in a certain approval category.

Current BTS systems such as the Debian BTS and the Red Hat Bugzilla could be extended to syndicate content. As they already have web interfaces and support automatically sending updates by email it should be easy to add the basic level of such support to them. But it might give a better result to go the other way and modify a multi-user blog system such as Wordpress-MU to have extra features for bug management.

BTS systems typically have bug ID numbers that increase sequentially while blog software typically gives something like http://blog.example.com/YYYY/MM/blog-entry-name.html when it's often more convenient to have something like http://bug.example.com/number. Of course it would not be difficult to have a little database that allows creating sequential numbers to map to arbitrary URLs in a similar manner to tinyurl.com. This could be either integrated into blog software (so that it says "bug #1234 has been created" or be available on demand (click a link to get a sequential number assigned). Incidentally using characters and digits for the short name of the bug (as done by tinyurl.com) would allow four characters to represent 1679616 bugs, this is enough for all bugs in the Debian and Red Hat bug databases combined. With tinyurl type technology there is nothing preventing us from having a single system creating unique IDs for all bugs in all distributions of Linux with a four character index (which is easier to remember than the 6 sigit numbers used in Debian and Red Hat at the moment).

I realise that most blog software will store the entries in a database which has sequential numbers assigned. So doing a database lookup to convert a human-readable URL into a sequential index when we have just done another database lookup to convert a sequential index into a human readable form is inefficient, but that's the way of things, computers do things inefficiently so that humans can work in ways that are efficient for them.

Note that throughout this post I refer to the Planet aggregation system, but really any of the aggregation systems can be used. One of the benefits of this is that people can use mailing lists, Google's reader, Planet, or any other reader they wish with the feeds. RSS feeds can be read by many programs and the user gets to choose which works best for them.