Re: debian/changelogs, legacy work on packages and other distros
On Sat, Feb 05, 2011 at 10:57:05PM +0100, Steffen Möller wrote:
> Well, maybe. I suggest to leave it with us for now and then evaluate the
> experiences we make over time. I tried to find what I once read about it,
> most likely in the Maintainers Guide, but there was only
> http://www.debian.org/doc/maint-guide/ch-update.en.html
> that suggests to write about the bugs that upstream has fixed.
It says explicitely:
Describe concisely the changes in the new upstream release
that fix reported bugs and close those bugs.
with "in the new upstream release" emphasised. Does this clarify my
point? If at all those upstream changelog snippets would have been
added to *previous* changelog entries of the Debian changelog.
> > really worth keeping but I would adapt to a "best practice" in our team
> > if you insist on this (it would be a good idea to fix this in our policy
> > then).
>
> ok -> policy
> > However, item 2. injecting a verbatim copy of *upstream* changelog just
> > into our packaging changelog is simply wrong and I *intentionally*
> > removed this information which does *not* beling to our changelog *on*
> > purpose because of educational reasons.
>
> Well, there is no separate changelog for TMalign. It is otherwise
> only in the source code and as such non-redundant.
You could add it as patch or in debian/upstream-changelog (whatever)
which makes perfectly sense (I actualla thought about adding this as
upstream documentation).
> And also it mentions the one or other bug that is closed,
... by different releases which have older changelog entries.
> which would be of interest to those
> who currently use the upstream sources directly of an older version.
To come back to the original question: It is not relevant for a Debian
or derivative user if bugs of some software which never affected any
Debian or derivative release. We simply should not put any burden on
ftpmaster to read irrelevant stuff and spend useless time. This let us
look not very clever and if we need immediate help in the future we will
have a harder time in arguing. That's my point why I want to try things
as simple as possible.
> > I know that Tim is a newcomer
> > and I just told him not to copy upstream changelog into the packaging
> > because this information is *not* about packaging.
>
> :) that was my idea when we sat together. Tim is innocent. We both
> liked it, though, thinking to have acted best for our users.
>
> Please check against http://www.debian.org/doc/maint-guide/ch-update.en.html
As stated above: You failed to regard the emphasised point and I tried
to explain this issue to Tim. If I'm not wrong he agreed to my reasons.
> Well, maybe "Several new upstream versions later" would then be even
> nicer. I see your point, but still like it. It is the short collection
> of changes that have been performed between two Debian packaging
> efforts.
I would prefer to move it to debian/upstream-changelog and install it
as such.
> > tm-align (20050601-1) unstable; urgency=low
> > ^^^^^^^^ this was never released
> fixed
>
> > tm-align (20110124-1) unstable; urgency=low
> > --> wrong changelog entry as mentioned above
>
> I like that changelog entry a lot and would not
> want to change it. As a compromise, I could offer to
> write a separate changelog as an extract from upstream.
> But not for this version, please.
>
> > tm-align (20110130-1) unstable; urgency=low
> > with entry "* Highly efficient debian/changelog."
> > signed by me - but I never added this entry.
> > and the Closes entry is missing
> >
> > tm-align (20110130-2) unstable; urgency=low
> > ^^^^^^^^
> > is not yet released (at least I did not got any confirmation from
> > ftpmaster and it contains the Closes phrase.
>
> Yes, I edited it to move the Closes up to the latest entry
> to make sure that it is closed. I removed that sentence on the
> changelog.
This is also something which does not help ftpmaster at all. Having
<upstreamversion>-n (for n>1) needs really good reasons for new packages
and this is definitely not the case here.
> Great. I do not see any larger danger of annoying the ftpmasters too much. After all, we are doing something as good as we can for
> our users and they certainly see this. That we have different opinions is natural. And that the ftpmasters have no particular
> interest in reading through changelogs of bioinformatics packages is also fairly natural.
I think the problem is quite generic and does not belong to the topic of
a certain science. The fact (keeping pre-Debian release changelogs) you
tried to discuss is valid and should be documented properly and this
should probably be done on debian-devel. We just have found a very bad
example here which mixes up several issues which do not belong to the
fact itself.
> > group policy - that's fine. I will try to keep this in mind and will
> > not strip it of in the future - provided that the entries are correct,
> > i.e. contain valid IDs are targeting at the correct distribution
> > (unstable is not a correct distribution for unreleased packages) and do
> > not contain information which just does not belong into a Debian
> > changelog.
>
> Sorry for many longish emails of today. To me it is a symptom that had quite an active week and are doing a lot of also novel
> things. There would be nothing to write about if we were just inactive.
Sure. In case I sounded angry - I do not think that I was. I was
concerned about giving newcomers wrong advise (which is quite easily
fixable) but even more looking foolish for ftpmaster which is not
helpful and not so easy to fix. I would not be astonished if they might
respond about this issue with a reject (or at least a warning). But
that's speculation. As a conclusion I would like to put the following
work items:
Group Policy:
1. Iron out the handling of pre-release changelogs.
2. Adding a hint that if upstream does not include a proper changelog
file this should be provided either as patch or as separate file
in debian/ and install it as upstream changelog.
Discussing handling of pre-release changelogs should be done either
before we put it in our policy (to learn about other groups experience)
or after we have a certain suggestion to propose it for other groups
as well.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: