Re: On Bugs

[Barak Pearlmutter <bap@cs.unm.edu>]

It seems to me that a big reason for the BTS having so many unclosed
already-fixed bugs, and incorrect severities, is that the user
interface isn't particularly convenient.  I'm not saying that what we
have now is awful, just that the simpler aspects of the functionality
it provides could be made more accessible.

A second reason for these problems is that the BTS has a number of
design and policy decisions towards the security end of the
security/convenience spectrum.  In this setting, I think moving
towards the convenience end should be considered.

Here are a few examples, along with concrete suggestions.

 - a web-based point-and-click interface to the BTS, allowing common
   operations to be done in a second.  Eg "CLOSE THIS BUG", "MERGE
   THIS BUG", "MODIFY SEVERITY", etc.

 - the policy is that only the maintainer or the person who reported
   the bug can close it.  That could be relaxed: have policy say that
   *anyone* can close it, provided they have good reason to believe
   the bug is actually fixed.  Have this cause email to be sent to the
   maintainer and original reporter telling them how to cancel the
   closing if they feel that is appropriate.  But if they take no
   action, it stays closed.

   (Clearly this *might* lead to escalating bug fights, and to
   sabotage.  But that would be an easy bridge to cross if it were to
   happen, which I doubt it would.  Eg by allowing the maintainer to
   "lock" a bug.  Besides, the BTS is already susceptible to sabotage
   from non-debian people.)

 - greater specificity of bugs should be allowed, perhaps by adding a
   "keywords" field with a short list of allowed keywords.  Eg
   "dependency", "build-error", "arch-only-sparc", "pre-post-inst",
   "fhs", "patch".  This might help with the psychological problem of
   people wanting to mark their bugs "special and important to me"
   and thinking "severity: important" is the way to do so.

 - we should encourage developers to keep their package sources in CVS
   and allow other developers write access to their repositories.
   This would make NMU's much more convenient for the actual
   maintainer, since their default (NMU fixed a real problem correctly
   and committed the mods to master repository) would require no
   action, not even integrating the patch manually.

   (Obviously this *might* cause problems.  But probably not, and
   they'd be very simple to deal with.)

I'm sure people with more experience than me can think of other
opportunities to optimize the BTS for the common case, in light of the
many years of use its seen since its initial design and enormously
successful