[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Horrific new levels of changelog abuse



Matt Zimmerman <mdz@debian.org> 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 we're talking about messages sent to
>> the -done address, possibly by hand.
> 
> I think it is a disservice to close a bug without making a notation in the
> changelog, if a change in the software fixed the bug.

Unless you're advocating retrocatively putting closure messages in the
changelog, this is not practically possible.  Some bugs will have to
be closed by hand.

>> In any case, this is implicit when the closure message comes from
>> debian/changelog.
> 
> It is only implicit if the bug and/or the fix are described in the
> changelog.  Otherwise, "Closes: #xxxx" by itself does not provide the
> required information.

That's what I said.
 
> 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 <low-level problem> in
> <subsystem> which caused <behaviour>), but it must be described.  In the
> case of closure messages sent by hand, there may not have been a change to
> the package, and so that does not apply.

Well, your "high level" change appears to be redundant as it is implied
by saying that the bug is fixed.

>> In this particular case, you closed a bug requesting for feature X with
>> the message that feature X was added.  Well I must say that this piece
>> of information could have been obtained with elementary deduction
>> even if you just said that this bug had been fixed in version Y :)
> 
> No, it would not.  The difference is between these two entries:
> 
> * Closes: #300000
> 
> * Correctly parse comments in the config file (Closes: #300000)

You're still thinking in terms of changelog entries.  Think in terms
of closure messages.  What is the difference between

Closure: Bug is fixed in version X.
Closure: Feature Y is added in version X.

where the bug is requesting for the addition of feature Y.

> If I am having a problem with comments in my config file, the first is
> worthless, and the second is very valuable.  The difference is that the
> change to the package is described, rather than hiding the change behind an
> opaque bug number.

In terms of closure messages, the two are equivalent assuming that your
original bug report is about comments in the config file.

>> As another example:
>> 
>> #204614: initrd couldn't detect EVMS root correctly
>> Closure: Detect EVMS root correctly
> 
> A high-level description of the change which was made.  Infinitely superior
> to "Closes: #204614".

Totally equivalent when we're discussing about closure messages sent
to -done.
 
>> * The bug is analysed and determined to be fixed before the said upload.
> 
> Bugs should only ever be fixed when they are analyzed (at some level) and
> determined to be fixed.  Too often maintainers mass-close bugs when they
> upload a new release after some time of inactivity, because they cannot be
> bothered to check (or even ask that the submitter check).

That's definitely a bad thing to do.  However, it is not relevant to
the discussion here.

>> That's OK with me.  However, if you wish to make everyone do that, then
>> may I suggest that you draw up a less arbitrary criterion than whether
>> someone has filed a bug about it in the Debian BTS.
> 
> I don't think that the presence of a bug report is at all arbitrary.

Well then this is beyond me.
-- 
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt



Reply to: