Re: Editing history... (about debian/changelog in experimental)
Frank Küster <frank@debian.org> writes:
> it seems to be consensus that one should generally not "correct" older
> changelog entries, like adding (closes: #...) if it turns out later that
> this bug had been closed by this release. I am wondering whether there
> is an exception to this rule, namely packages in experimental. The
> changelog of tetex-base in experimental looks like this:
> . . .
> However, there are some bugs that I didn't know they were fixed when I
> did the upload, it only turned out later. Therefore putting a "closes"
> into the changelog entry of a *later* beta release does not make sense,
> and I wonder whether I shouldn't simply add them to this list in the
> first experimental upload, although it's an older changelog entry.
>
> What do you think - shouldn't I edit the list of closed bugs in this
> first experimental changelog entry?
I personally feel that adding new changelog "blocks" is okay but
editing old changelog blocks isn't okay, even if you are going to do a
subsequent build with a -v when you go back to unstable. I would
either close the bug manually or put an entry in the latest changelog
block with a parenthetical remark saying that bug was actually fixed
by version x.y-z. I feel that if you grab any old version of a
package, the changelog should look identical to the current changelog
after you remove all blocks whose date is later than the date of the
old version.
> On a related note: If I do uploads of 2.0.2c to unstable while 2.99 or
> 3.0 is in experimental, shouldn't I copy the changelog entries to the
> appropriate place in experimental's changelog, too? This is also kind of
> "editing history"; however if I don't do it, the changes made to 2.0.2c
> will be only documented in the changelog of the stable release, and if
> there's some revision that never makes it to sarge, it will be lost
> almost entirely (except for snapshot.debian.org or similar).
I just went through this same issue with tiff. After a brief
discussion on IRC, I decided to make sure that the package in
experimental (now subsequently uploaded to unstable) had all the
changelog entries of the changes made in unstable in order by
revision. My question was really whether it would be better to go in
order by revision or in order by date. We decided to go in order by
revision because it is less confusing to the eventual reader. (I
never checked to see whether the -v flag to dpkg-buildpackage would
work correctly if I went in order by date. That could be another
reason.)
Between my (sponsored) upload of 3.7.0-1 to experimental and 3.7.1-1
to unstable, there were two security fixes (3.6.1-4 and 3.6.1-5) to
unstable and one additional upload (3.7.0-2) to experimental. I
inserted them in revision order in the changelog of the experimental
package which ultimately made it back to unstable. I did this even
though the new version was actually completely repackaged and the
latest upstream version already had the fixes. In other words, I
didn't actually have to change the experimental at all other than to
add the changelog blocks.
I did not, however, update the changelog with the security team NMUs
made to the much older version in stable. That seemed rather
pointless (since the stable version of the package was several
upstream versions back), and had not been done by previous maintainers
prior to my inheriting the package. A case could be made that I
should have done that as well so that the latest version uploaded
would reflect the entire upload history of the package. This would,
for example, give someone a chance to double check that security fixes
applied to stable had also been applied to unstable. On the other
hand, anyone doing such a check shouldn't rely on someone having done
that. Anyway, changes to stable are definitely in a different
category from changes to unstable....
My opinions should, of course, not be construed as "consensus" since
I'm definitely a newcomer. I consider them worth posting though
because they came partially from a discussion on IRC that involved
people of greater experience. :-)
--
Jay Berkenbilt <ejb@ql.org>
http://www.ql.org/q/
Reply to: