Re: RFH: Where/How to setup RCS for new libfuse-ocaml package

[Goswin von Brederlow <goswin-v-b@web.de>]

Stefano Zacchiroli <zack@debian.org> writes:

> On Mon, Mar 02, 2009 at 08:30:48PM +0100, Goswin von Brederlow wrote:
>> There is no pristine tarball and I don't intend to ever release
>> anything without a debian dir. There is no upstream svn
>> repository. There is just the fully debianized source. A native
>> Debian package.
>
> Note that there is QA consensus that having as native Debian packages
> softwares which are not Debian-specific is a bad idea. libfuse-ocaml
> is definitely not Debian-specific and IMO you should release it
> without a debian/ dir inside. It is pretty easy to do too, just add an
> exclude pattern to tar and you are done.

That implies that I publish it somwhere and test build and use it as
non Debian package, which I won't. I don't feel comfortable making a
release I never use.

> I'm personally responsible of a bug in that respect for ocaml-http,
> which currently is a Debian native package while it should not. I
> consider it as a current bug in the package which should be fixed.
>
> Nevertheless, if you want to go ahead and use d-o-m infrastructure to
> maintain libfuse-ocaml by all mean go ahead, we will not inhibit that
> on the basis that it should not be a native Debian package. QA sooner
> or later will take care of all such packages.
>
> Nevertheless, if you are going to use d-o-m infrastructure please
> follow our rules / best practices. In particular, choose whether you
> want your package to be team-maintained or not. If yes, put "Debian
> OCaml Maintainers" as Maintainer and yourself as an Uploader. Also,
> please set up commit notifications on IRC and mail; we have scripts to
> automate that.

Maintainer and Uploader is already set. Hooks are on my ToDo. Is it ok
to just copy the hooks dir from e.g. dh-ocaml?

> If you do not want your package to be team maintained, keep yourself
> as the Maintainer but please coordinate with us for transitions and
> other ocaml-wide changes.
>
>> Can git-buildpackage work on native packages? Is there a quick guide
>> on how to configure for that?
>
> It is the same as with non-native packages. With the default settings
> you will simply happen to have upstream always in sync with
> master. I still suggest using pristine-tar + git-import-orig, it is a
> sane workflow also for native packages.

Expect that it is much more work as you have to manage each branch in
turn instead of just one branch. Not to mention maintaining 2
changelogs and 2 todo lists.

> Cheers.