Dealing with disagreements on bug handling
On Fri, May 11, 2001 at 04:00:24PM -0500, Taral wrote:
> I recently filed a bug which the maintainer insists on closing with
> "Sorry, but this works." It is a real problem on my system, and I
> consider it somewhat irresponsible of the maintainer to continue to
> close the bug. What are the developer guidelines on this, and what can I
> do (besides reopening it) if this problem persists?
AFAIK there are no formal guidelines, which is good, because it is easy
to make some, but very hard to make good ones.
IMHO you should try to do the most sensible thing for the case at hand.
Suppose this happens:
You notice some strange behaviour in a program.
You file a bug, in which you try to give a most accuracte description
of the problem.
In all your communication about the bug, you ensure to include the bug
tracking address in the recipient list of your messages. As a result,
other developers, taking up interest in the case at a later, date can
find the whole discussion properly archived for later reference.
The dispute about the bug remains unresolved between the submitter and
the maintainer and noone steps in with a conjugating point of view, or
the discussion still leads to a situation dissatisfying to either the
submitter, the maintainer or any others taking an interest in the matter.
Your last action in the discussion up to that point and in that scope,
is to announce that you have lost confidence in the continuation of the
present discussion, but that you are still very convinced of your point
of view, the superiority of your technical arguments, the affront that
you have taken from the treament given to you by the maintainer, or
<insert favorite pet cause here>.
You carefully restate your original case, a summary of the discussion,
include some references, like bugs.debian.org/<bugnumber>, and finally
your current point of view. You crosspost this message to debian-devel
and the bug tracking address. You do not add any other addresses
in the header, especially other mailing list addresses, fearing that
you might annoy people and bias their opinion in your case.
If nobody outside of the already involved parties responds, all parties
may draw their conclusions about the relevance of the issue and reflect
on the length to which they still want to pursue the case.
If the discussion is however picked up on debian-devel, it is now out of
your hands. This is both good, because it brings in many new angles and
possible solutions, as well as bad, because some will bring in their own
pet causes and start sidetracking the issue and trigger many flamewars.
Maybe the bug submitter is flamed for his ways, maybe the maintainer.
Maybe there will be a decent discussion among sensible people on the topic
of proper ways to deal with issues that are bugs and bugs that are issues.
Maybe there will be an ensuing flamewar that lasts for months ;-)
Somewhere in the now much broader discussion, some developers may perceive
an important underlying issue of debate and attempt to seek resolution
by means of policy making. Or they may just try to be pragmatic and
fix the things that are broken.
Maybe some well-defined part of the issue is finally taken all the way
to the Tech Committee. At least then the issue has been debated upon by
developers and obvious nonsense has been eliminated and obvious solutions
have been probed. What has been said is archived in the mailing lists,
so that people can be referred to it when they need to do their homework.
Please allow the Technical Committee to be an institution of unpeccable
respectability, not as an easy stick for anyone who happens to need one.
I'd hate to see it turned into a bureaucratically self-propelled, vulgar
instrument of random folly or abuse.
Cheers,
Joost
Reply to: