Matt Zimmerman [EMAIL PROTECTED] wrote:
Totally equivalent when we're discussing about closure messages sent
to -done.
A message to -done means nothing to anyone except the bug submitter. The
three seconds I spend writing a useful changelog entry make it useful to me,
the submitter, and
Herbert Xu [EMAIL PROTECTED] a tapoté :
Matt Zimmerman [EMAIL PROTECTED] wrote:
Totally equivalent when we're discussing about closure messages sent
to -done.
A message to -done means nothing to anyone except the bug submitter. The
three seconds I spend writing a useful changelog
Bernd Eckenfels [EMAIL PROTECTED] wrote:
On Sun, Sep 21, 2003 at 11:55:37AM +0100, Mark Brown wrote:
Simply saying that the bug was fixed in the new upstream release doesn't
tell the user why
Why a bug wa gixed is obvious, because it was a bug.
- XXX does nt delete temp file
- Fixed in
Matt Zimmerman [EMAIL PROTECTED] wrote:
- a user to be able to read the changelog, with an idea of the bug in
his head, and find where it was fixed. For example, a stable user
reading an unstable changelog to see if a bug affecting him is fixed
This is not relevant I'm afraid since
On Tue, Sep 23, 2003 at 07:20:59AM +1000, Herbert Xu wrote:
Matt Zimmerman [EMAIL PROTECTED] wrote:
Both should record the change in the package which caused the bug to be
closed. The change may be described at a high level (fixed the problem
which caused behaviour) or a low level (fixed
Matt Zimmerman [EMAIL PROTECTED] wrote:
- The bug submitter should receive a reasonable explanation for the bug's
closure in the -done message
Well can you please give an operable definition of what a reasonable
explanation is?
A reasonable explanation includes enough information
On Mon, Sep 22, 2003 at 09:22:40PM +1000, Herbert Xu wrote:
Matt Zimmerman [EMAIL PROTECTED] wrote:
A reasonable explanation includes enough information for:
- the submitter to recognize that their bug was in fact fixed
Agreed. However I must say that this is pretty obvious when you
On Sun, Sep 21, 2003 at 04:18:10PM +1000, Herbert Xu wrote:
Matt Zimmerman [EMAIL PROTECTED] wrote:
I think I do understand your position; I simply disagree. I feel that
changes which close Debian bugs should be documented in debian/changelog
whether or not they are Debian-specific
On Sun, Sep 21, 2003 at 11:00:14AM +0200, Thomas Hood wrote:
On Sun, 2003-09-21 at 10:21, Herbert Xu wrote:
The only disagreement is with what to do with upstream changes that
happen to close Debian bugs.
Is there any chance of everyone agreeing to leave it up to the
maintainer to decide
On Sun, Sep 21, 2003 at 02:56:35AM -0400, Glenn Maynard wrote:
On Sat, Sep 20, 2003 at 05:38:50PM -0500, Adam Heath wrote:
As far as the BTS is concerned, it is irrelevant how a bug is fixed.
Wrong. The BTS is a front-end to users. When bugs are closed, the
submitter(a normal user)
On Sun, Sep 21, 2003 at 11:55:37AM +0100, Mark Brown wrote:
Simply saying that the bug was fixed in the new upstream release doesn't
tell the user why
Why a bug wa gixed is obvious, because it was a bug.
- XXX does nt delete temp file
- Fixed in new upstream release
I mean, hell this is not
Bernd Eckenfels [EMAIL PROTECTED] writes:
Why a bug wa gixed is obvious, because it was a bug.
- XXX does nt delete temp file
- Fixed in new upstream release
I mean, hell this is not hard to understand.
That's great if I knew what the bug was. You seem to be assuming that the
only people
This seems like a lot of argument over avoiding putting six more words
into the changelog file giving information that the maintainer clearly
already has (since otherwise they wouldn't know that they could close the
bug), and which is obviously useful for users.
Hear, hear.
You can't tell
13 matches
Mail list logo
