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:
Heh.
I'd like to see some or all of the following added to debbugs:
CGI-based web pages
-------------------
Yay!
Get the bugs archived
---------------------
Yay!
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".
Yay!
Change the database format
--------------------------
Awww.
Yay!
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
debian-boot@lists.debian.org:redundant-questions
debian-women@lists.debian.org:easy
joe.bloggs@example.com:fileserver-upgrade-issue
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.
Cheers,
aj
Reply to: