Re: Horrific new levels of changelog abuse
On Mon, Sep 22, 2003 at 09:22:40PM +1000, Herbert Xu wrote:
> Matt Zimmerman <mdz@debian.org> 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 get
> a closure message.
>
> For those who're only satisfied with detailed analysis of how a bug
> is fixed, may I remind you that no matter how long the bug closure
> message is, the possibility remains that the bug was not fixed at all.
Detailed analysis is not necessary, but I think that at a minimum a
description of what bug was _believed_ to be fixed is valuable, as this
helps to catch errors with closing the wrong bug, misinterpreting the
submitter's problem, etc.
> > - 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.
> > - a developer to be able to determine what version of the package he
> > needs to depend on if he requires a certain fix which was requested
> > through the BTS
>
> This is a good idea and we probably should get people to start doing it.
> However it would be good if the BTS provided a formal way of specifying
> it.
I believe Colin Watson is working on this, but I imagine it is a major
undertaking.
> 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.
> > - the changelog to stand on its own, and be useful without digging
> > through the BTS
>
> Again this is not relevant as we're talking about messages that may be
> sent by hand.
>
> So to summarise, you haven't given me an operable definition of what a
> reasonable explanation is that applies to both debian/changelog messages
> and closure messages sent by hand.
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.
> > Can you provide an example? The rootstrap example you gave certainly
> > provided more information than "bug #xxxx was fixed"; it documented the
> > addition of a feature which justified the closure of the bug.
>
> 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)
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.
> 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".
> > My position on changelogs is completely unrelated to the BTS, because I
> > think that the changelog should stand on its own, documenting all
> > changes to the package which are considered relevant to Debian.
>
> Fair enough. In that case the basis on which upstream changes are listed
> in debian/changelog should not be dictated by whether they fix Debian
> bugs. Otherwise this would appear to be farily arbitrary as it
> depends on the following three conditions to be true:
>
> * The bug is filed in the Debian BTS.
> * The bug is filed before the relevant upstream release is uploaded to Debian.
Obviously bug fixes cannot be documented if the maintainer is not aware of
them at the time.
> * 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).
> > I do feel strongly that changes in the package which are relevant to Debian
> > users and developers, whether they happen to be in the debian/ directory or
> > not, should be documented in debian/changelog.
>
> 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.
--
- mdz
Reply to: