Mon, 20 Feb 2006
Item one: debbugs has moved from CVS to bzr.
Item two: it’s well past time I came out in support of Mary Gardiner’s brief guide on pronouncing “bzr”.
Item three: don’t you find the Sugababes’ latest pop ditty really quite catchy?
Put them all together, and what do you get?
Mon, 10 Oct 2005
Usercategories and other miscellania
So, this week’s AJ Market project was the first couple of items on my debbugs TODO list, viz:
- Finish off usertag support
- 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
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.
Hrm, request@ changes actually updated on bugs.debian.org now. I knew committing to debbugs CVS promptly would come at a cost...
Fri, 12 Aug 2005
Mikal writes:
Why do I use Debian? Well, one of the reasons is the bug reporting.
People in Mikal’s shoes might’ve noticed a few changes in the Debian bug tracking system (BTS) lately, such as the long awaited roll out of version tracking to help us deal with tracking bugs amongst the multiple versions of packages across stable, testing, unstable and experimental, and bug subscriptions, allowing you to track an individual bug by email, should you so desire. We’ve also added both Don Armstrong and Pascal Hakim to the BTS team (though at the time of writing the Organisation page hasn’t been updated).
These changes are, of course, just part of a vicious plot by my fellow team members to make my debbugs talk at dc5 completely out of date as soon as possible; so the value of the paper and slides and the video are depreciating pretty rapidly, but not so much I won’t link them.
One nice thing is that all the features mentioned in my talk are now implemented (although all of them could do with some improvement). What’s this mean?
Fri, 01 Jul 2005
I’m giving a talk on debbugs at debconf5. Since they’re trying printed proceedings and are planning on handing them out in advance of the talks, I wrote up a paper that should be useful background material for people interested in hacking on debbugs. This is the abstract:
This paper aims to serve as a useful reference for people attending the talk of the same title at DebConf 5, to be held in Helsinki, Finland from the 9th to the 16th of July 2005. It summarises the primary motivations behind the design philosophy of debbugs, the on-disk data formats debbugs uses, and the overall structure of the code. It aims to provide sufficient background on the current status of the debbugs codebase that the interested reader may use as a basis for beginning to hack on the debbugs codebase. Basic familiarity with debbugs from a user’s perspective is assumed.
And you can find it on my CodeWiki.
I’m also meant to be doing a BOF on debootstrap. It seems to have turned into some sort of faux-keynote, being the first talk of the first day without any other scheduled activity, which it’s massively unsuitable for. I’ve tried harassing the organisers into changing it for me, but they seem to want me to spend my time before leaving finding some other speaker to swap with, which I don’t have time for. On the upside, if nothing happens and I remain with an effective keynote slot, I have hatched an evil alternative plan, albeit one that crucially relies on the exact scheduling given. If it eventuates, folks looking to attend a debootstrap BOF should probably expect an unofficial one over a lunch sometime instead.
In other timetabling news, it seems Mark Shuttleworth is giving a talk on a small project called Unubtu or something. Apparently there’s not much interest, and most people will be going to Junichi Uekawa’s library packaging talk instead. Talks on obscure topics like the DSFG are also, unsurprisingly, not attracting much interest.