Hi,
adrelanos wrote (25 Jan 2013 15:51:17 GMT) :
> I have no experience with Debian packing,
I strongly advise the read of this introduction to Debian packaging:
apt-get install packaging-tutorial
> however tails_htp looks fairly doable for a beginner.
Sure thing.
> A upstream repository has been created:
> https://github.com/adrelanos/sdwdate
> Since the Debian folder shall not be added to the upstream package by
> policy, I could create another one:
> https://github.com/adrelanos/sdwdate-deb
When one is both upstream and package maintainer, one generally uses
one packaging branch and one upstream branch in the *same* repository.
> The package has been renamed to sdwdate because I think tails_htp
> would not be accepted in Debian and calling a fork like the original
> project is also not desirable. The name however can be changed.
When a piece of software has been abandonned by the original upstream
author for long enough time (no upstream release, author reply neither
to bug reports nor to patches proposal), I don't call it a fork if
someone else start to seriously take care of the software.
In my experience, Debian is often happy to call "upstream" anyone who
actively plays the role of upstream in such situations.
So, if htpdate effectively seems abandonned its author (who should be
consulted about this, BTW), and someone is willing to be the new
upstream, then I don't think a rename is needed (and it adds to the
confusiand and makes it harder for potential users to find it).
If nobody is willing to be the new upstream, then this software should
probably not be added to Debian anyway.
> I am not eager to become upstream,
FWIW: I've always changed the htpdate code in Tails repository in
a way that I hoped some upstream would some day be happy to merge my
stuff, but I don't want to be "upstream" of it (e.g. I would not want
to reply to bug reports unrelated to Tails or review others' proposed
patches). Contributing the features Tails need, on a case by case
basis, is fine for me. And if there's no upstream, well, then I'll go
on the same way.
> but I like to see this package in Debian.
So would I. With my Debian developer hat on, I'd happily sponsor
uploads for a commited maintainer who's either skilled enough or
willing to learn and not expecting much guidance from me.
> Any comments, advice, wishes?
It would make collaboration with me if you settle on debhelper + a Git
workflow close to the standard git-buildpackage one. It has to be
slightly modified when upstream and Debian packaging live in the same
repository, though: see e.g. the parcimonie or tails-persistence-setup
Git repositories for how I like to do it.
> Do you like to have write access?
I don't think this will be needed. We can always send pull requests :)
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
