Re: Bug o' the week
On Wed, 15 Sep 1999, Brian May wrote:
> I think the index would have to sometimes be decreased so that large
> and complicated packages that everybody uses (eg X-Windows) get a fair
> rating.
Yeah. Another idea would be to divide by the total number of bugs,
so that the resulting number would be an `average severity'. Bugs
might need to have an `average severity' below 3 to be *automatically*
included in `frozen'.
> - forgetting the bug exists - does this occur?
Undoubtedly, yes.
> - not enough time (in this case the maintainer should ask if
> somebody else is willing to fix bugs for the package).
Again, yes, but I suspect far too seldom does anything get done
about it. This is what the QA team are supposed to fix, to some
degree.
> - don't know how to fix it. Maybe there should be some
> sought of flag on the BTS for this category. Anyone can
> find a list of bugs which the author doesn't know how
> to fix, and help (if possible).
Yes, a `request for external help' flag in the bug, hm. Of course,
with the QA team, all the maintainer should need to do is to
mail QA asking for it to be put on the tasks list.
> - bugs that cannot be fixed without a major redesign of the
> program.
These tend to be upstream bugs, and probably shouldn't be counted.
> - not sure you entirely believe bug report, but want to leave
> bug report open anyway, just in case. bug reports aren't
> always accurate, and it is possible that the reporter
> made a mistake, but cannot be verified as such
> by the maintainer. Or perhaps the bug is specific
> to the reporter's computer system, and doesn't apply
> to Debian. Some people might consider downgrading
> these to wish list - I don't think this is a good
> idea (the bugs might be serious problems). I can't
> remember what the policy says.
I think this is a problem, yes. This is why I've argued against
using the BTS as a way of automatically deciding whether people can
upload stuff to `unstable' against `frozen', and so on: bug
management is a more organic art than some people seem to think.
> - waiting of upstream fix (in this case it should already
> be marked as such in the BTS).
Probably shouldn't be counted then.
> - work in progress.
Perhaps an ETA field could be added in the BTS (in weeks?), which
would mark the bug not counted.
> - fixed but not yet uploaded.
Probably not relevant. BTS latency is quite high, anyway.
> Maybe somebody needs to investigate why the majority of bugs still
> exist... Or maybe it should be possible to assign one of the above
> category codes to each bug report?
I'm hoping the QA team might make some progress.
> Another suggestion: for "work in progress", it might be a good idea
> if the author could attach an "estimated completion time" to the bug
> report. This would give others some indication of when a fix is going to
> be provided, or if the maintainer has got bogged down with other things
> and run out of time. It wouldn't have to be accurate, and wouldn't
> matter if the maintainer is late, but in that case other people may
> volunteer to help.
Oh, you suggested it as well. :) Yes, I think there should be fields
that cover `in progress', with an ETA attached. A developer might do
something like this:
* Check the bug list, find a bug, send a command to BTS saying
"I'm working on this, ETA 2 weeks".
* If the bug isn't closed within 2 weeks, the bug goes back to being
marked `inactive', and the developer will be sent a reminder.
--
Chris <chris@fluff.org> ( http://www.fluff.org/chris )
Reply to: