Re: Bug o' the week

[Brian May <bam@snoopy.apana.org.au>]

In article <[🔎] Pine.LNX.4.10.9909150350510.13529-100000@inkvine.fluff.org> you write:
>I've had another early-morning idea.  I think a metric called a
>"bug index" should be invented.  It would be calculated like this:
>every severity of bug would be given a weight, say:
>
>  critical:  5
>  grave:     4
>  important: 3
>  normal:    2
>  wishlist:  1
>
>Then the bug index would be calculated by summing the number of bugs
>in each category (for that package) * the severity weighting.
>
>Extra weightings could be added for age, or whether the bug is
>an upstream bug, etc.

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.

Just another thought. There are several reasons I can
think of why a maintainer might leave a bug unfixed. I am
not sure how common each point is.

- forgetting the bug exists - does this occur?

- not enough time (in this case the maintainer should ask if
  somebody else is willing to fix bugs for the package).

- 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).

- bugs that cannot be fixed without a major redesign of the
  program.

- 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.

- waiting of upstream fix (in this case it should already
  be marked as such in the BTS).

- work in progress.

- fixed but not yet uploaded.

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?

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.

-- 
Brian May <bam@snoopy.apana.org.au>