Re: RFS: mercurial-server
On 11/09/11 21:02, Jakub Wilk wrote:
* Paul Crowley <paul@lshift.net>, 2011-09-09, 11:12:
(I'm afraid I'm not subscribed to debian-mentors - I'm checking the
mailing list archives - please could you Cc: me in responses? Thanks!)
(Done!)
Thank you!
Since we surely cannot release mercurial-server in such a state, yes,
filing it would be in order.
Done: http://bugs.debian.org/641262 (I accidentally filed a duplicate
http://bugs.debian.org/641263 but I think I've done what's needed to
merge that with 641262 now).
I've also uploaded a new version of the package to mentors.debian.net
which is Lintian-clean. http://mentors.debian.net/package/mercurial-server
I don't quite understand. Is preparing a new version somehow
particularly costly?
The cost of making a new release of trunk is not borne by me, but by the
people using trunk - so I've gone for the easy fix, and rolled CREDITS
back to the way it was in trunk. Everyone has credit in the head
sources and will get it in the next release.
Why debian/watch is empty? Upstream seems to be providing versioned
tarballs, so that should be easy to write.
I've added this now.
I am upstream ;-) When I wrote that I was using the "archive" facility
of Mercurial to provide the tarballs, and there was no way for uscan
to scan that. However these days I make a special tarball that
excludes some cruft from the sources, so uscan could scan for that.
Naturally it will never be useful since usually send the Debian files
to the sponsor before I even upload that tarball,
That's an odd work-flow...
Why is that? I work on both together and don't make a release until I
think that both are ready to go.
I see. This kind of bugs beg for a test-suite. :)
There is a test suite, but at the moment it doesn't sufficiently
exercise the ruleset code - the test suite creates a chroot environment,
it's more aimed at catching install issues.
Thanks again - hope this is ready to sponsor now!
--
[][][] Paul Crowley
[][] LShift Ltd
[] [] www.lshift.net
Reply to: