Changelogs (Re: Bug#193497: marked as done (svtools: svsetup uses bashism "echo -e"))
On Thu, Jun 12, 2003 at 07:46:34PM +1000, Herbert Xu wrote:
> I guess then you're targetting the people who're reading the Debian
> changelog rather than someone who's looking at the BTS.
Yes, absolutely. As a Debian user, the changelog is where I look to find
changes which affect me. The BTS doesn't even attempt to perform this
function.
> If that's the case then this is suboptimal. The reason is that only bugs
> that happen to be filed prior to the first Debian release of the new
> upstream version are noted that way. This is incomplete for someone who's
> looking for a list of upstream changes from a Debian perspective.
If no bug was filed in the BTS, then the fix for the bug may not be
significant enough to Debian users to be worth noting in the changelog
anyway. If a bug is filed against an old version, then it should simply be
closed, and there is no need to try to document something which changed a
long tame ago.
> It is my opinion that it is better to not list them at all in order to not
> give the read a false impression that these changes are in any way
> representative.
It is my opinion that it is better to make the laughably small effort
required to make the changelog more valuable. There is clearly no fault in
excluding information that you do not have, nor in excluding information
which you deem to be unimportant. However, I would argue that changes
relating to existing, open bug reports are decidedly valuable to include.
This is also useful, in a different way, when upstream does not include a
useful changelog (kernel-source, for example).
> If you're targetting people reading the BTS, then my previous argument
> still stands: the only piece of information that is necessary for the
> closure of bug #xxx is that it's fixed in version x.y.z.
My position has never been about the BTS at all. I keep changing the
subject line of this thread, but then I pick up at a different point (which
is also talking about changelogs, but has not changed the subject).
> > It is clearly useful to associate bug reports with the corresponding fixes,
> > and upstreams do not, in general, reference Debian bug reports. This is one
> > reason why the upstream changelog is not a substitute for useful Debian
> > changelog entries for upstream changes.
>
> But what purpose does it serve if it only lists *some* of the bugs.
It serves the purpose of documenting the fact that a change was made which
has direct bearing on a Debian bug report, when that information is
available. I am not suggesting that anyone document information that they
do not have, but that is no reason not to document information that is
directly available to you.
> This could be improved if we included retroactive bug fixes, e.g.,
>
> foo (x.y-2) unstable; urgency=low
>
> * Fixed in previous release by upstream:
> . Fixed crash when reading from IDE device (closes: #xxx)
>
> -- .....
>
> foo (x.y-1) unstable; urgency=low
>
> * New upstream release.
>
> -- .....
>
> Is this what you're advocating? If not, what good is it?
Why would I advocate this? It is completely inappropriate to close such
bugs using the changelog mechanism, because they are not being fixed by that
upload. How I handle such bugs is to try to reproduce them on the current
version, and then if I fail, I ask the submitter to try to reproduce them
with the current version. If the current version solves their problem, I
close the bug report. I do not make an upload with an entry in the
changelog for this purpose; that would be wasteful. I just send mail to
#-done explaining that the bug does not exist in the current software.
--
- mdz
Reply to: