Re: Random BTS musings
On Mon, Jul 30, 2001 at 06:20:39PM +1000, Anthony Towns wrote:
> On Mon, Jul 30, 2001 at 12:58:13AM -0400, Matt Zimmerman wrote:
> > Where is the source to bugscan, or whatever the tool is called which generates
> > the bugscan reports? Is that the same tool which generates the RC bug web
> > pages?
>
> I'm not sure what you mean by bugscan reports as opposed to RC bug
> web pages. The RC bug pages are generated by scripts in ~wakkerma/
> on master. There are other scripts elsewhere, including in ~ajt/.
I mean the reports sent to debian-devel-announce which say (I think) "Bugscan
report for <date>...". Since the web pages mention "bugscan" as well, I assume
it is the same script. I'll look at master:~wakkerma.
> > My issue with tags is that they don't reflect the logical structure of the
> > information that they are supposed to represent, and data presentation and
> > accessibility suffer. The concept of "tag" is different from "severity" is
> > different from "status". Why not use tags for severities, too?
>
> Because implementing in the way that it is implemented was
> convenient. Severities happen to be mutually exclusive, [patch, pending,
> wontfix, help, moreinfo, ...] by and large aren't. There's nothing
> fundamental here, it's just an implementation decision. It's vastly
> difficult to change, but only in the same way that it would've been
> vastly difficult to implement it any other way.
>
> If you don't like the presentation, suggest a better one.
As an experiment, I've created a relational schema for storing the bug
database, and have successfully imported current information for a few thousand
bugs. This includes submitter, package, status, severity, merge status, tags,
forwarding address, done address, and all of the message logs. Reporting is
nice and snappy.
The only information that has been lost is the history of the bugs, since some
of this is difficult to reproduce from the bug logs. For instance, when a bug
is merged, the complete list of mergings is given, not just the ones that were
most recently executed. I think I'll have to re-parse and re-execute the
commands in the control emails to preserve that information. Blecch.
> > > > qa.debian.org already has a system for tracking higher-level tasks and who is
> > > > responsible for them, but it isn't integrated with the BTS.
> > > ?
> > I'm talking about the program at control@qa.debian.org.
> > http://qa.debian.org/bot-quickref.html
>
> Is that all there is, or is there some way of actually getting a list
> of current tasks and such too, or is it a write-only system? Is that
> actually being used? (At least during the bugsquash parties, I've mostly
> seen the /topic of #debian-bugs being used for coordination)
http://qa.debian.org/todo.html
I have rarely seen more than a couple of tasks there, but it seems like it
could be useful if used more, and better integrated with the BTS (it could
mostly implement the assigning bit that we talked about).
--
- mdz
Reply to: