Re: debian/changelogs, legacy work on packages and other distros
Hi Andreas,
On 02/05/2011 07:05 PM, Andreas Tille wrote:
> I guess you are addressing my actions in some cases where I adopted the
> work which was done by somebody else.
Close, indeed, I was writing a comment about TM-align to you and I thought
that more on this list might possibly want to think along.
> 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.
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. My main
concern was that the removal of a package's pre-Debian-release history
might be of concern for the exchange between Bio-Linux and us. Hence
my immediate reaction.
> The last case where I'm guilty for this action is beast-mcmc.
[ ... I don't know beast-mcmc ... ]
> 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.
Up to here we agree.
> Regarding never released packages
> with no real information about packaging changes or things which should
> really be kept in mind I consider it different.
Here we do not.
>> 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).
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. And also it mentions
the one or other bug that is closed, which would be of interest to those
who currently use the upstream sources directly of an older version.
> 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
> 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"
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.
> 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.
> 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.
I fixed things as laid out above.
>> 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.
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.
> 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.
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.
Many greetings
Steffen
Reply to: