Re: On Bugs
Adam Heath wrote:
> This is only a preliminary set of commands. None of these have been
> implemented yet. Also, the list of allowed keywords would have to be
> something that all developers agree on. Ie, 'fixed', 'patch',
> 'waitingOnSubmitter', 'WONTFIX', others?
Wow, noone else has replied. I'm sure this will have changed by the time
I get on the net again though (flying to ALS).
Here is a list I roughed out this morning:
Mark what distribution a bug affects, if it only affects some.
Should be obvious.
Maintainer needs someone to help with this bug for some reason,
and can't pass it upstream for some reason.
Bugfix patch included.
Bug is just recording a NMU. (Typically also has patch keyword
Bug has been fixed, maintainer has not closed yet.
(NB: The release manager's RC bug scanning tools would have to
disregrard RC bugs if they had this keyword set.)
Bug is a security problem.
Maintainer prefers to not fix this bug/thinks it is not a bug
(mostly appropriate for some wishlist items).
For the debian QA bugs; they can stop using the title of the bug
Making "fixed" a keyword should be elaborated on: I've long been annoyed
that it is a bug severity since whether a bug is fixed is really
orthagonal to its severity. Now IIRC, the original reason we introduced
fixed at all was so bugs could be marked as dealt with after a NMU,
without the danger that they would be expired right out of the BTS
database in 30 days. That is no longer a danger with the BTS archive. So
I don't really know if we need the concept of "fixed" at all any more;
if we do I'd prefer we start denoting it with a keyword instead.
Adam, you mentioned that you think this should be a defined list. I can
see benefits to that, but I hope it remains easy to add new items for a
while, and I also hope the BTS behaves sanely if it gets a keyword it
doesn't know about. I'm sure bug submitters will start including
keywords soon enough, and occasionally get them wrong.
see shy jo