Hello world,
There's been a bunch of changes to the BTS over the past couple of
months, pretty much leading up to, during, and following debconf [0].
These are the next two. :)
The first feature is "usertags". Tags have been pretty handy (even if I do
say so myself), but there are always new tags people what and often they
don't end up getting them because they're too special purpose. The obvious
fix (if you count something that takes five years to come up with obvious)
is to let users define their own tags that are only visible to themselves.
The mechanics are simple. You send a mail to request@bugs.debian.org
(which contains the subset of commands from control@bugs.debian.org that
don't affect anyone else) with something like the following:
user aj@azure.humbug.org.au
usertag 18733 + good-reasons-to-run-for-dpl
usertag 18733 + still-cant-believe-it-finally-got-fixed
usertag 62529 + your-days-are-numbered
The "user" command says which user the usertags are for; it'll default
to the address in the From: or Reply-To: header of your mail. The
"usertag" command works just like the regular "tag" command, except you
get to make up whatever tags you like.
The UI for actually using the tags isn't fully developed yet, but
there are three main ways in which you might want to think about using
the tags. The first way, is just viewing them, which you do by adding
";users=<address>" to your url. eg:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?
pkg=lsb-core;users=debian-lsb@lists.debian.org
will show you an "lsb" tag on bug#302009. Useful for annotating bugs, so
if you always wanted a "ask-submitter-where-i-can-get-some-of-those-drugs"
tag, this is your chance. As you might've guessed, you can put multiples
addresses in by separating with a comma (,).
The second way is to use a tag to select interesting bugs -- there's not
really much use knowing that an lsb-core bug is lsb related, but being
able to list all the lsb-compliance bugs no matter which package, well
that sounds more interesting. You can do that pretty much the same way:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?
tag=lsb;users=debian-lsb@lists.debian.org
That'll tell debbugs to look at all the tags debian-lsb has set, and
prepare a report of all the bugs tagged "lsb".
The third way is where we get to the second new feature.
Imagine you have 30 open bugs; maybe 7 of them are packaging bugs, 9
are documentation bugs, 8 are bugs in the user interface and 6 as bugs
in the actual internal implementation. One nice thing to do might be to
tag the bugs according to this, and then have debbugs display the bugs
according to those tags so you can more easily look at bugs that are
related to each other, and generally feel a bit more organised as you
try to fix them. Depending on what sort of categories you might want
(and how many bugs you have!) you might end up with something like this:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?
pkg=ifupdown;users=ifupdown@packages.debian.org;
pri0=tag:easy-or-standalone,vars-for-scripts,syntax,
interface-dependencies,hotplug-issues,script-enhancements,
ifconfig-stuff,ifstate-with-options,update-options-from-up-results,
allow-logical-to-physical-mapping,selection-of-config-tool,
unwind-on-failure,hurd,crazy,examples-needed
(aka: http://tinyurl.com/ac2yy)
We'll see how that works in a second.
In summary, though, usertags are just like regular tags, except that
they're only visible once you've added an appropriate "users=...." field.
The rules are pretty simple: whoever owns the email address gets to decide
what tags should exist, what they mean and when they apply. One person's
"crazy" tag might denote clinical insanity of the submitter, another's
might be to denote the bug is "crazy... like a fox!" and actually a
great idea.
We don't make privacy guarantees; but usertags do have a limited amount
of privacy in that we're expecting not to advertise the addresses of
which users have set usertag, and usertags are not not shown unless you
*explicitly* request them, so as long as you don't use the maintainer's
email address, your personal usertags won't get in their way. For the
moment, nobody is notified when usertags are changed, but it's likely
that in the fairly near future that'll change to let the "user" be Cc'ed
if anyone else tries changing their usertags.
Hopefully there won't be any fights over usertags -- there's plenty of
room for everyone to set their own; but if there are, disputes'll be
resolved in accordance with the wishes of the email address's owner. As
usual there aren't any restrictions up front on who can do what.
Some sample uses you might want to think about:
* keeping track of particular bugs that affect users
(breaks-webserver-in-datacentre-5) or a derivative distribution
("patched-by-us" might indicate that when the bug is fixed, the
derivative can use the pristine Debian package, or at least remove
a patch)
* keeping track of bugs that affect policy goals, such as the LSB
example above; the debconf to cdebconf stuff might also be an
example, as might the /usr/doc stuff. this is a similar use case
to that of blockers -- the difference being more visibility in the
"pkgreport.cgi" display, and that a dummy bug (eg, "Debian is not
LSB compliant") isn't needed
* keeping track of automatically filed bugs, such as lintian errors
* organising work on your packages
* keeping track of lists of bugs in ways that help random people fix
them ("missing translation into __", "fix needs some C skills",
"just needs some documentation written", ...)
So, the other new aspect is the category changes. The basic idea is that
instead of being hardcoded, the way the BTS splits bugs into sectios is
now dynamic, and can be configured via CGI variables like "nam0", and
"pri0". The defaults look like this:
nam0=Status
pri0=pending:pending,forwarded,pending-fixed,fixed,done,absent
ttl0=Outstanding,Forwarded,Pending Upload,Fixed in NMU,Resolved,From
other Branch,Unknown Pending Status
ord0=0,1,2,3,4,5,6
nam1=Severity
pri1=severity:critical,grave,serious,important,normal,minor,wishlist
ttl1=Critical,Grave,Serious,Important,Normal,Minor,Wishlist,Unknown Severity
ord1=0,1,2,3,4,5,6,7
nam2=Classification
pri2=pending=pending+tag=wontfix,pending=pending+tag=moreinfo,
pending=pending+tag=patch,pending=pending+tag=confirmed,pending=pending
ttl2=Will Not Fix,More information needed,Patch Available,Confirmed,
Unclassified
ord2=2,3,4,1,0,5
The priority line is the important one, and tells debbugs what it should
look for to put bugs in a section. Sections are checked in order, so a
bug that's tagged "wontfix" and is "outstanding" will be put in the Will
Not Fix classification, even if it's also tagged "patch". Normally,
sections are sorted in the order they're given, but if that's not what
you want, you can set the "ord" field to give the order you do want.
As well as doing all this on the command line, there's a pretty kludgy
javascript based form at the bottom of pkgreport.cgi now that will let
you set some cookies to store the settings and reuse them later. There's
also a link to my development notes, fwiw. Here're some instructions
that have worked for some:
1. load http://bugs.debian.org/cgi-bin/pkgreport-helix.cgi?pkg=ifupdown
2. look for "(beta)"
3. usertags from: ifupdown@packages.debian.org
4. name 1: ifupdown TODO
5. sections 1: tag:easy-or-standalone,vars-for-scripts,syntax,interface-dependencies,hotplug-issues,script-enhancements,ifconfig-stuff,ifstate-with-options,update-options-from-up-results,allow-logical-to-physical-mapping,selection-of-config-tool,unwind-on-failure,hurd,crazy,examples-needed
6. name 2: status
7. press "Commit"
8. reload the page
9. look for "Options"
10. check for the new entry in "Categorise bugs by"
Anyway, like I said, it's a bit "beta" (okay, a lot), but it's somewhat
usable, and I'm worried if I keep working on it rather than getting it out
there I'll have so much to try to explain in one hit my head'll explode.
Heck, maybe yours has already.
I'm hopeful this'll be useful to people and maybe even a bit
inspirational. If you do start using it, you might like to add a note to
the Debian wiki page [1], so we can get some idea what sort of things
people /actually/ find useful and interesting and make the UI work for
that, rather than just implementing whatever sounds like a good idea,
or happens to be easiest.
Thanks particularly to Margarita Manterola and Erinn Clark for acting
as sounding boards and offering inspiration and advice, and to other
folks on #debian-women (Moray Allan, James Troup, David Nusinow, Pascal
Hakim, Hanna Wallach, Helen Faulkner, Rob Weir, and perhaps others I've
forgotten), for being either helpful or guinea pigs or both :)
Cheers,
aj
[0] Blocking bugs, min/maxdays, bug subscriptions, version tracking,
prettier bug report pages, prettier package report pages, ability
to change options from the package report pages rather than just by
editing urls or going back to the main page, internal changes to how
mail works that fixes some long standing bugs, some internal support
to make cookies plausible, a couple of new members to the BTS team,
maybe some other stuff I've forgotten...
[1] http://wiki.debian.org/bugs.debian.org/usertags
Yes, that is wiki.debian._org_ .
Attachment:
signature.asc
Description: Digital signature