Re: Random BTS musings
On Sun, Jul 29, 2001 at 09:39:58PM +1000, Anthony Towns wrote:
> On Sun, Jul 29, 2001 at 02:52:46AM -0400, Matt Zimmerman wrote:
>
> [Matt recommends Bugzilla-esque tags]
>
> Some of these are already available:
> [...]
I noted in my descriptions where these status values corresponded to current
tags. Part of my suggestion was to represent status information as such,
instead of with a collection of "tags" that are also used to represent things
like security-significance, which release affects, a bug, etc.
It also seems to be impossible to do reporting based on tags, though that is
arguably a fault in the reporting tools.
> > "New/Unconfirmed"
> > "Verified"
> > "Assigned"
> > "Reviewed"
>
> These sorts of states always strike me as not really appropriate for Debian.
> I don't think anyone's even vaguely interested in having anything even
> vaguely resembling formal reviews of patches and such. From what I've seen,
> the QA team already has its hands full keeping orphaned packages in order and
> helping out with RC bugs; expecting them to go through every new flag and
> verify/review/confirm the report, or talk to the reporter to get a real
> report just seems kinda unreasonable.
I personally find myself having to bring up the bug in a browser and read
through the messages just to find out whether progress has been made on a bug.
I usually find one of these situations:
- There is only the bug report. The maintainer may or may not have even seen
it.
- The maintainer and submitter are engaged in collecting more information about
the bug, or arguing about what should be done. The bug report is not
necessarily incomplete, but there is more work to be done.
- The correct fix has been determined, and no help is needed.
- The maintainer is MIA, and someone else has reproduced and is trying to help
resolve the bug. They may provide a patch, and may follow up with an NMU
eventually.
All of these states look the same in the current BTS reports, and they are not
represented by current tags either. The RC bug list is huge, and every bug
requires a miniature investigation to determine what its status is. I'm not
suggesting that the QA team be responsible for handling all bug reports, just
that we keep more detailed status information in the BTS.
The review process, as I said, may not be appropriate for Debian at present,
but it is an important software development concept, and there are open source
projects which implement code review.
> The only thing which people actually do atm which the BTS doesn't really
> support is to help coordinate QA work on bugs (eg during bug squashing),
> which could be fixed by a "tag" that lets you say something like:
>
> tag 123456 taken-by=ajt@debian.org
This is part of what I suggested, but is again represented implicitly by a
"tag" instead of explicitly recording the progress of the bug.
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.
> > "Released"
>
> Having to go through every bug fixed between potato and woody's release
> and change a flag on it isn't likely to be at all fun. Even just keeping
> the bugs open is really more than the BTS can cope with. Not that this
> wouldn't be somewhat useful; just that it's a /lot/ of work, either in
> the short term or over the long term.
>
> > I would like to create a system where bug status could be tracked without
> > having to read through the messages in the BTS. Each time I scan through the
> > RC bug list, or skim debian-bugs-dist, I have to read the messages for the bug
> > to determine what is happening with it. If we were to keep track of bug
> > status, more effort could be focused on the bugs which need the most help.
>
> There're "help", "moreinfo", "unreproducible" and "patch" tags. There are
> three open bugs marked help [44065, 93885, 94298], 115 marked moreinfo,
> 124 marked unreproducible, and 405 marked patch, that haven't been NMU'ed
> or closed yet.
>
> I don't really think it's plausible to expect -qa to fix all those bugs,
> so I don't really think adding a new tag (or equivalent) and expecting
> -qa to look through all of these bugs is plausible either.
I agree. I'm not suggesting that -qa fix all those bugs, nor that we add any
new tags. Tags aren't even displayed by bugscan, or anywhere else except the
web pages, and that makes them less useful than they could be. Even if they
were, we're trying to represent a single item of information (status) with the
bitwise OR of a bunch of random tags, and by stuff in brackets in the title of
the bug.
> > Is any development effort still going into debbugs, or should a replacement
> > be written?
>
> debbugs CVS is on cvs.d.o in /cvs/debbugs, module "source".
Doogie was rumoured to have been working on a SQL backend, but I don't think
that work is in CVS yet. It's often hard to tell from CVS whether a project is
active or not.
--
- mdz
Reply to: