Re: changelog bug-closing should not be used unless the code changes
Chris Waters wrote:
> I'm not sure I agree with the much-more-friendly part. I'd rather see
> a descriptive changelog entry than a terse and uninformative separate
> email. Basically, I'd say friendliness has more to do with style than
> with delivery mechanism.
I think that using a delivery mechanism that is explicitly *talking to*
someone, rather than making a comment in a file that is not part of a
conversation, tends to result less often in terse and uninformative
things like:
* Unreproducable, probably fixed in 2.2, closes: #57026, #42726, #40768
closes: #45848, #58367, #62990, #40870, #67296, #38897, #60099, #66769
(No offense meant to Ben really, I just had this example handy.)
> Now, if I have information that doesn't seem appropriate to the
> changelog, but does seem like it might be interesting to the original
> submitter, I'll send that in a separate email, but in that mail, I
> usually say that I'm *going* to close the bug, and I still use a
> changelog entry to do the actual closing.
That's silly. Why should I record "It was user error, Closes: #nnnnn" in
my changelog? My program has not changed.
> I might even go so far as to suggest that we should deprecate all
> other methods of closing bugs, and use the changelog entries as our
> *preferred* bug-closing mechanism. Therefore, if Ian is making a
> policy proposal, I firmly oppose it.
And I would more than firmly oppose any such misguided proposal as that one.
Good grief, think for a minute about a maintainer with a perfect package who
gets a bug report that is really an error between chair and keyboard. You
really want him to upload a new version of his package just to close that bug?
--
see shy jo, who won't even start on the problem of uploading a new version
of ftp.debian.org to close a bug against it
Reply to: