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
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 submit
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 ) or a low level (fixed
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 a
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
> -
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
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
> 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 te
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 pe
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
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 norma
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
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-spe
13 matches
Mail list logo
