inamerrata

So, this week’s AJ Market project was the first couple of items on my debbugs TODO list, viz:

1. Finish off usertag support
2. Implement usercategory support

Both of these are essentially followup for the initial usertags announcement from last month. The usertags cleanup amounted to adding some basic documentation which will hopefully make it to the website soon, adding some users to various views by default (currently the @packages.debian.org address for package and source queries, and the maintainer and submitter address for maintainer and submitter queries), limiting the characters that can be set in usertags so they don’t conflict with the characters the CGIs are willing to display, and suchlike.

Some other minor niceties, such as docs for the block command, summaries of blocking issues on the pkgreport pages, and a cute mrtg graph for monitoring the BTS’s spam related delays, also made it in.

The bulk of the work though went into the usercategory feature. The idea of usercategories is to let you sort bugs into more suitable categories than the defaults, and to leave working out what those are to individual maintainers and users. The previous possibilities were to stick them into the URL as CGI parameters (possibly via a tinyurl redirect, or a link on some other page), or to use cookies locally after filling in a form. Neither worked really well, so the solution instead is to allow you to create a named usercategory via the email request/control interface, and reference it by name in the URL. The URL syntax is just to add an

;ordering=development-view

option to the pkgreport.cgi URL; and the request bot syntax is:

To: request@bugs.debian.org

user bugs.debian.org@packages.debian.org
usercategory dev-priorities [hidden]
 * Development Priorities [tag=]
  + Sorting Features (should close) [sorting-close]
  + Usertag Related Features (should close) [usertags-close]
  + CGI Related Features [cgi]
  + Changes to rewrite rules [rewrite-rules]
  + Bug Subscriptions [bug-subscriptions]
  + Bugscan Problems [bugscan]
  + Index problems [indexes]
  + Spam Control [spam]
  + Documentation [doc]
  + Re-education Camp Required [inflexible-view-of-the-world]
  + Random Features [random]
  + Can be closed? [should-close]
  + Unprioritised bugs []

usercategory development-view
 * dev-priorities
 * status

The leading spaces are optional; the asterisks and plusses aren’t. Asterisks denote a new level, and plusses denote a section within the level. You can define a prefix for the level as a syntactic convenience. You can either define each level in full, or by reference to a different category, in which case that category’s level(s) will be inserted. If you later change “dev-priorities”, “development-view” will be correspondingly changed. Usercategories are listed in the drop down box in the Options form, though only as long as they’re not marked “[hidden]”.

The above lists the tags in the order they should be looked at, so if a bug has both “random” and “should-close” as usertags, it’ll be listed under “Random Features” not “Can be closed?”. That’s the order those sections are listed in too — but that can be changed by adding an explicit ordering, such as:

  + Random Features [7:random]
  + Can be closed? [5:should-close]

A nifty trick, which won’t necessarily continue to work, is the possibility of creating a usercategory called “normal”, which will overwrite your default view of the bugs, particularly if its assigned to a user whose tags and categories are automatically available, such as the packages.debian.org, maintainer and submitter addresses.

In theory that should be enough to make usercategories actually usable. There are certainly some bugs remaining, but they don’t seem to get in the way too much.

UPDATE 2005/10/10:

Hrm, request@ changes actually updated on bugs.debian.org now. I knew committing to debbugs CVS promptly would come at a cost…