[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: My Wishlist

On 2002/10/27 2:30 PM, Anthony Towns wrote:
So, a blast from the past:
On Mon, Sep 13, 1999 at 11:03:41PM +1000, Anthony Towns wrote:


I'd like to see some or all of the following added to debbugs:
CGI-based web pages

Get the bugs archived

Per-Release Reports
I also think it'd be nice to be able to say "these bugs are relevant to
slink, these to potato, and these to experimental".


Change the database format


Integrated Reports
We've got a few cutesy bug summary things about, including -bug-reports,
the RC bugs list, the old bugs list and the non-wishlist graph. I'd like
to see all these generated by the BTS itself, and made available on the
website. With graphs and all.
Awww. :(

I guess this is almost a yay too, though the reports aren't really very integrated. I'm not really sure if we should do anything about this beyond gradually improving bugscan. It certainly feels a lot less interesting now.

So, almost six years later, they're all done! Sweet.

I guess my wishlist for debbugs now is something like:

  1) User modifiable tags
  2) A replay-able log format
  3) Direct external access to the debbugs db
  4) Refactor the mail distribution (subscriptions, -submitter, etc)
  5) Refactor errorlib/common.pl into a clean perl function library
  6) (Re-)templatise all the user-interaction

In detail.

  1) User modifiable tags

I think this will probably turn out to be a big win for the BTS's users; it'll allow you to do things like have "lintian.debian.org" automatically file bugs for bad FSF addresses, and set a tag "E-bad-FSF-address" so it can monitor when the bugs get closed to save filing duplicates. That example itself mightn't make sense, but the ability to manage auto-filed bugs well is likely to be a win; especially if it allows us to correctly mass-close bugs that shouldn't've been auto-filed. :)

The idea is to have a "User-Tag:" field, either in .summary or in a separate file, that includes entries like


The user tags would then be visible only if you "subscribe" to the appropriate email address, so if you're involved in debian-women and debian-boot, you see that it's a redundant-questions bug, and that it's easy, but you don't ever notice that joe.bloggs had a fileserver-upgrade-issue due to this bug (well, unless he emailed about it).

  2) A replay-able log format

Redoing the log format would be nice; I think a good measure of whether we've ended up with a good format is whether or not we can "replay" it; that is, only keep the .log file, and from that, regenerate the .summary file. Doing that means we've got some sort of format that can be easily parsed to see how the emails were interpreted, which can then let people do queries like "aiee, show me the bloody email that set this bug to serious". And with a parsable log, we can then generate the html that says "Bug was set to severity serious" live, which also means those notes can be translated, if anyone cares enough.

  3) Direct external access to the debbugs db

There's two aspects to this. One is being able to rsync (or similar) the spool dir; the other is some sort of programmatically accessible index interface. We've been using ldap for that. This ought to be easy; I just don't know what a good protocol is. I don't think ldap is it.

  4) Refactor the mail distribution (subscriptions, -submitter, etc)

Having mails to 123456@bugs.d.o not go to the submitter is probably crazy; especially with bug subscriptions it makes sense to just treat 123456@bugs.d.o as a mailing list with all the people interested in the bug already subscribed. Sometime soon, we can probably arrange to just push all the mail out to our magic MLM, and have that then get forwarded on to everyone who's interested, rather than actually sending mails to maintainers, submitters, the PTS, etc ourselves.

  5) Refactor errorlib/common.pl into a clean perl function library

This has needed to be done for years. I'm not terribly interested in doing it. :)

  6) (Re-)templatise all the user-interaction

Likewise, I guess. It's possible we should come up with a new template format; text.in isn't great.

There're some other things people're interested in: particularly some good ways of looking for bugs against a package in different distros (Debian based or not) to see if they're needed; and an easy way to deal with bugs in Debian-related distros that aren't actually in Debian. I tend to think those should probably be dealt with outside debbugs and outside Debian respectively.


Reply to: