Branching changelogs or not (Was: debian/changelogs, legacy work on packages and other distros)
[Reply-To set to debian-devel]
Hi,
on the Debian Med list a discussion about handling changelogs was started[1]
which addressed the following questions:
1. What to do with pre-Debian-Release changelogs (if packaging
needed some time and went through several intermediate steps
before it was uploaded to ftp.d.o (with the special case of
releases in other distros).
There was the conclusion to basically keep this changelog
entries.
2. Whether upstream changelogs should be copied fully or in
parts copied into Debian changelog and I think the New
maintainers guide[3] gives a clear answer to mention only
the changes of this *new* release specifically if these are
closing known bugs in Debian and not just random features
of the new release and definitely not changes of old
releases.
3. Whether changelogs should be branched for different Debian
releases, be it testing-proposed-updates, backports or even
derivatives as Ubuntu or others.
Even if those problems are concerning the topic "Debian Changelog"
I would try to keep the discussion into different threads and my
answer below concentrates on the last question.
On Sun, Feb 06, 2011 at 09:33:58PM +0900, Charles Plessy wrote:
>
> I often fix errors in my changelogs a posteriori when I find them. I think that
> if a package was never uploaded to unstable, the changlog should not mention an
> upload to unstable :) So I would recomment fixing.
ACK.
> Actually, now that backports.debian.org is official and Squeeze is released, we
> will have more headaches with changelogs. For instance, should the changelog of
> the upstream branch mention that the package was backported ? Currently, I keep
> a different changelog for each branch, because I am mostly using Git now. But
> in the packages in the Subversion repository, managing branches is a bit more
> complicated, so the “linear” way may fit better.
IMHO a changelog is just a text file which should be regarded
independently from any VCS - as it is presented to the users in the
installed package. The question in fact is tricky as the issue with
release managers and gnumed-client[3] has turned out. They seem to
force branched changelogs which I feel inappropriate in the long run
even if I accept the reasoning RM has given in principle. However, I
would like to have one single file which tells me about any release that
happened. In the gnumed-client case I branched according to the release
manager request (hated myself for doing so) and added the entry later on
manually into the main branch. The whole workflow is at best suboptimal
and only acceptable for very view exceptional cases. I'd highly regard
any suggestion which promises a better workflow.
> And to be comprehensive, let's not forget contributions form Ubuntu. One entry
> in the latest versions's changelog, or one full changelog entry where the
> upload is not targetted at unstable ?
As far as I know the Debian changelog is untouched in the Ubuntu porting
process as far as the packaging itself is not changed. (Please correct
me if I'm wrong!) In turn *if* there is an Ubuntu changelog some need
for a change has occured and I would just like to know about this (to
decide whether we should take it over or not. So, *if* any Ubuntu (or
other derivative) changelog entry has valuable content ("repackaged for
distro XYZ" is not valuable content IMHO) we definitely should keep /
clone this entry. However, this has the problem that we probably should
explain if and why those changes are taken over (or not). In short: The
changelog file could be (mis?)used as a channel for communication.
> Confusingly,
Added confusion
Andreas.
[1] http://lists.debian.org/debian-med/2011/02/msg00048.html
[2] http://www.debian.org/doc/maint-guide/ch-update.en.html#s-newupstream
[3] http://lists.debian.org/debian-release/2010/12/msg01054.html
--
http://fam-tille.de
Reply to: