Re: Horrific new levels of changelog abuse
Matt Zimmerman <mdz@debian.org> 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 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.
In fact, it is only common courtesy for any bug sumitter to verify
that a bug is indeed fixed. After all, it would be terrible waste
for the maintainer to spend time and effort in correcting a bug, only
to be foiled by what may be a simple mistake/misunderstanding that could
be picked up by the submitter.
> - 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.
> - 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.
In any case, this is implicit when the closure message comes from
debian/changelog.
> - 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.
>> I've read a number of closure messages on bugs of your packages, and
>> they really coveyed no more information than a message which simply
>> said that the bug is fixed in version x.
>
> 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 :)
As another example:
#204614: initrd couldn't detect EVMS root correctly
Closure: Detect EVMS root correctly
> 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.
* The bug is analysed and determined to be fixed before the said upload.
> 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.
--
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: