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 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~} <[EMAIL PROTECTED]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt