Re: [Ian Jackson <ian@chiark.greenend.org.uk>] General bug policy
Hi,
After reading through the mail every one has sent in, I have
come up with a revised set of rules. My comments are unindented.
manoj
1. In the first instance a package maintainer may decide
whethere a bug report not justified and close it if they
feel it isn't.
2. If the submitter (or anyone else) disagrees they should
try to resolve it by email with the maintainer and/or by
discussion on this list. During this period the submitter
may choose to reopen the bug (and mark it unforwarded if
necessary).
Removed the injuction to assign this to policy. The policy package is
not a catch-all for all disputes; though a policy proposal may grow
out of some disputes, this should by no means be automatic.
3. If this discussion reaches an impasse the technical
committee will have to decide on the problem. When it is
clear that this has happened the submitter or maintainer
should ensure that the bug is open and unforwarded
I removed the rule that noone but the maintianer should close the
bugs. I have found that I appreciate the times when a reporter
discovers it is not a bug, and closes reports, or when someone
discovers why it is not a bug, or that it is the fault of another
package. I suggest we follow common courtesy in this also, and
refrain from mass closures, or closing a report again after someone
(possibly the maintainer) reopens the report.
I see no useful purpose in insisting the maintainer has to be the
_only_ person who can close bugs. (NMU's may not close bugs -- they
may merely set them to the state fixed, so that is not an issue).
I also propose the following guidelines for determining whether a bug
report should be kept open, etc.
1. Bug reports represent defects in the software that should
be remedied. Wishlist items represent misfeatures or
extra functionality, or any other area where a change
would be useful or good.
2. A bug is still a bug if the upstream authors are aware of
it - even if the upstream authors disagree that it is a
bug. Bugs of which the upstream authors have been made
aware (whether they disagreed with the report or not) can
be marked `forwarded' but should not be closed. The
package maintainer need not mark such a bug as forwarded -
for example, they may intend to fix it themselves.
The package maintainer may decide if this is not a bug, if it is a
wishlist (bug), or it is a real bug (in which case the maintianer
disagrees with the upstream author).
2a. However, all reports of bugs which are bugs in the
upstream version of the package should be forwarded
upstream, possibly sanitised or with patches, but in any
case without delay.
3. A bug is still a bug if it has been assigned to the wrong
package or the way to fix it is unclear or there are other
problems with the report in question. Reports of such
`difficult' bugs should not be closed. If there is doubt
about the correct assignment of a report it should be
assigned to `debian-policy' and discussed there.
4. Change requests for changes which would not be useful or
good should not be left as open wishlist items. See above
for details of what to do in case of dispute.
manoj
--
Don't guess -- check your security regulations.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Reply to: