On Tue, Jun 03, 2003 at 07:42:05AM +1000, Herbert Xu wrote: > Matt Zimmerman <[EMAIL PROTECTED]> wrote: > > Yes. There is no record in the package that a bug report in the Debian BTS > > was closed in this version. What about other users who experienced the same > > Why should that be in the package? What if you didn't know at the time that > the bug was fixed in this version?
You obviously can't document what you don't know. This discussion was about closing bugs in the changelog (which obviously implies that the maintainer knows that they are closed) without explaining why. > > bug? Is it so hard to explain what bug was fixed, and if possible, how > > it was fixed? > > Remember that I'm talking about closing a bug in the BTS by hand. I'm talking about changelogs. > > Would you upload a new kernel-source saying "Closes: #242141" rather > > than "apply patch from 2.6.48 to fix root security hole in nanosleep()"? > > If this is fixed by upstream, yes. I would simply say > > * New upstream release (closes: #xxx, #yyy, #zzz). > > When I open up a Debian changelog, I expect to see what the Debian > developer has done to it. I don't mind seeing changelog entries > explaining upstream changes as long as they're clearly marked. And I > would be most concerned if people start putting them in without marking > them as upstream. When I open a Debian changelog, I expect to see changes which are pertinent to Debian development. This obviously includes changes which affect the status of Debian bug reports. As for attribution, I do not think this is a problem in practice, but this is the format I use: foo (2.1.1-1) unstable; urgency=high * New upstream release - use snprintf rather than sprintf to prevent a buffer overrun (Closes: #528432) - do some other things which relate to how this package is used in Debian * Build-Depends on more recent libbar * Don't forget to install the documentation (Closes: #879242) It is perfectly clear what changes are made by whom, and how these changes affect Debian bug reports. -- - mdz