Re: debian/changelogs, legacy work on packages and other distros
Hi Steffen,
I guess you are addressing my actions in some cases where I adopted the
work which was done by somebody else. My handling was inspired by
probably only aural discussion with ftpmaster (I admit I have not found
any written document about this) who was bored about long pre-Debian
changelog entries which just consumes their time. If you are really
concerned about this topic I would suggest to move the topic to
debian-devel because I do not see the point to keep this hidden in the
Debian Med circle.
The last case where I'm guilty for this action is beast-mcmc. You can
inspect the changes I did in the changelog in SVN[1].
I would like to mention that I definitely needed to change the changelog
because the Closes statement needs to be in the latest changelog entry
and not in the first one. I contacted the former maintainer Felix
Feyertag including CC to the devel list[2]. Usually I would have waitet
longer than just three days before taking action but I'm a bit under
pressure with these packages. If you look at the former changelog in
SVN[1] you see only a series of "New upstream version" and anything
remains unreleased. There is nothing about packaging changes or
something like this. So I decided it was not worth keeping (and as we
have a VCS it is not definitely lost if somebody cares). (Moreover all
changelog entries of Felix were done with a broken ID which did not
had a valid e-mail address.)
On Sat, Feb 05, 2011 at 02:03:26PM +0100, Steffen Möller wrote:
> I have not seen it in the Debian policy document, yet, but at least for the packages I co-maintain with Ubuntu developers myself
> (all outside of Debian Med if I am not erroneous) and from what I read on the lists, it is common practice to just extend the
> debian/changelog file. It is never shortened.
I agree that a changelog of a package that was *released* at the Debian
mirror should definitely not be shortened (neither should it be forked
as release team forced me to do in gnumed-client 0.7.10 unfortunately).
I would even agree if there was a first release in Ubuntu or any other
derivative *and* we take over the packaging stuff that we should keep
the Ubuntu/other history in any case. Regarding never released packages
with no real information about packaging changes or things which should
really be kept in mind I consider it different.
> The idea behind this is that we all steadily improve the package, and knowing about
> the changelog allows to estimate the gain of functionality that may be observable in the one or other distribution. And of course
> it also helps to pinpoint to the one responsible for the good or the bad, without a dig in the repository's logs. One possible
> effect is that the debian/changelog is already fairly long before it first hists the Debian server. Nobody should mind.
>
> Another source of packages that I would want to render you aware of are those packages that we create for ourselves. Those, that
> are never truly meant to be uploaded to the servers. I personally for instance create a Debian package for about everything that I
> evaluate locally. And a basic package is fairly simple to create, so I just do it. It does not cost much extra time. And finally,
> the final package is just so much easier to get removed from the disk again after the evaluation. And I do not need to fiddle with
> the PATH too much. In most cases, such packages never go anywhere. But sometimes those are submitted to the Debian Med repository.
> And we just had the case, that for a recent release of T-Coffee, the structural alignment program TMalign was suddenly of
> interest. This was one of those "should be in Debian Med" packages that is kind of there but not really ready for an upload. The
> ITP pending because of a missing license file and then forgotten. It was then found by Tim who has then with support by Andreas
> completed the packaging. Lovely. In my mind, the debian/changelog file should then remain intact, i.e. not be resetted to a
> "Ininital release (Closes:..)" kind of minimalist version. The package had a previous life also outside the distribution. And we
> would weaken our community when we just forget about that initial development time. That reason not to upload may be technical or
> due to a temporary lack of interest. The package nonetheless should not forget about its history.
Just lets look at this case in SVN[3]. IMHO you are mixing up two
different cases:
1. Keeping the old history of the not yet uploaded package
2. Bluring our packaging changelog with upstream changelog
Item 1. is perhaps topic of discussion. I would not mind if you would
consider the pre-release changelog important and would like to add thhis
history. I would take the freedom to apply common sense if something is
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).
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. 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. The information is
even *wrong* because the entry which says
"New upstream version"
mentiones features of *all* upstream versions which is not a valid
changelog entry at all. If (at all) a valid entry would have been:
"New upstream bugfix release"
to declare the nature of the upstream change or something like this. We
do not add copies of upstream changes to our packaging changelog - there
is an extra file (see man dh_installchangelogs). If upstream does not
add a changelog file I'd regard it as proper action to create a separate
file debian/changelog.upstream and copy the information to this file.
To make things worse we have in SVN now a completely broken changelog:
tm-align (20050601-1) unstable; urgency=low
^^^^^^^^ this was never released
tm-align (20110124-1) unstable; urgency=low
--> wrong changelog entry as mentioned above
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.
That's all quite broken and I would like you to fix this please to make
the changelog a real source of information as you requested.
> The issue is strategically important for me because of yet another reason. With an increasing adoption of bio-IT in the drug
> development process, we are likely to see many more tools that are not redistributable for Debian, but that allow for a local
> compilation of the sources. For those tools, and for instance Rosetta is not something that one could too easily ignore, a support
> through Debian would not get any further than to our subversion repository, i.e. the sharing of the debian folder with all the
> build instructions, with its build- and runtime-dependencies. NAMD and VMD are other examples. I do not know for the latter, but
> for Rosetta I know the community support to be excellent, shared between academic groups around the globe. I want those experts to
> consider Debian more for their development and for their sharing through it. Hence, let us experiment with an exchange of package
> build instructions, let us strengthen our Debian Med developer portal's code sharing mechanism and let us accept the
> debian/changelog files as an essential brick towards that.
So back to your point: I could perfectly live with keeping the
pre-release history and your reasoning is perfectly valid to stand
against a potentially angry ftpmaster. So lets iron out this in our
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.
> Steffen (who after all this writing has finally decided to upload the sources for his Rosetta package)
Cool.
Sorry if I tipped on somebodies shoes and please bring the tm-align
changelig in correct shape.
Kind regards
Andreas.
[1] http://svn.debian.org/wsvn/debian-med/trunk/packages/beast-mcmc/trunk/debian/changelog?op=diff&rev=0&sc=0
[2] http://lists.alioth.debian.org/pipermail/debian-med-packaging/2011-February/008732.html
[3] http://svn.debian.org/wsvn/debian-med/trunk/packages/tm-align/trunk/debian/changelog?op=diff&rev=0&sc=0
--
http://fam-tille.de
Reply to: