Re: Bug#23355: PROPOSED] On closing of bugs
> On Tue, 1 Jun 1999, Julian Gilbey wrote:
>
> > Santiago Vila wrote:
> > > Well, what I would like to see is a general policy about bugs, covering
> > > all aspects of bug reporting, forwarding, severitying and closing. Who is
> > > allowed to do that, and when. For example, how many times are a submitter
> > > allowed to reopen a bug (I would say that only once), or how do we decide
> > > about a bug being normal or wishlist (current practice says package
> > > maintainer has the last word about this).
> >
> > No, we just need some common sense, common courtesy (which none of us
> > seem to be so good at ;), some good relaxation techniques and some
> > good interpersonal skills.
>
> My experience says this is not enough.
But policy won't be either. And remember, this is only *your*
experience. See bug reports #24067 and #38544 for two examples: one
with you as submitter and one with you as maintainer. I have yet to
find an example not involving you. (BTW, I found #24067 when I was
working through the -policy bug reports and #28544 involved me. I
have *not* been actively looking to find such bug reports, much less
ones involving you.)
> > Just being able to throw policy against a bug-submitter doesn't
> > prevent something from being a bug. And just submitting bugs against
> > a maintainer doesn't make it one.
>
> Certainly.
Therefore policy won't help.
> > Maybe there should be something in policy about disputes, but I would
> > guess that if there is a dispute, it would usually mean that there is
> > something akin to a bug present.
>
> I disagree. This is like saying that somebody reporting *anything*
> and disputing afterwards is enough to have a "bug".
Find me any example of this not involving you and I will listen to you
again on this subject.
> > And if the maintainer doesn't want
> > to "fix" it, he should at least not close the report, leaving the
> > reasoning present in the report.
>
> IMHO, the BTS should track all Bugs, and should only track feature
> requests at the option of the package maintainer.
That's what wishlist items are, and the BTS *will* track them.
> A maintainer should not be forced to track a feature request in the BTS if
> he/she thinks it does not worth the effort or it not of value.
No. If the feature request is impossible to provide ("please ask this
WM to handle something handled directly by X" was an example I had
recently), then it is reasonable to explain that the request is
impossible. However, lack of time or inclination, or a value
judgement that "it is not of value" should be marked as such in a
reply to the requester and left in the BTS. If we only record things
that we have time to do, then there will almost never be any wishlist
bugs, and the software will not develop. Someone may look at a
package's wishlist requests and say: "Hey, they're right, that's a
great idea! I'll go away and implement it." And you would lose that
opportunity if you removed wishlist bugs just through lack of time.
Incidentally, I don't think anyone will bemoan the fact the a given
developer has a lot of open wishlist items. A lot of open normal and
higher bugs, maybe, but a list of feature requests is not something to
be embarrassed or ashamed about. I've even submitted wishlist bugs
against my own packages for things I've wanted to see present.
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. J.D.Gilbey@qmw.ac.uk
Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Reply to: