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 Tue, Mar 03, 2009 at 01:30:37PM +0100, Goswin von Brederlow wrote:
>> 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.
>
> It is not true that you never use it. You use it as the base for your
> packaging, you test it when you build your .debs. Also, this enables
> Debian side to do releases for Debian-only modifications without
> having to re-upload everything.
>
> Remember that given how OCaml is made, you usually have to bump build
> dependencies before uploads and that is a (recurrent) example of
> Debian-only change. Why you want to force your non-Debian users to
> have a new upstream release for things they will not care about?

That would be a minor release. Non-Debian users don't have to package
every minor release.

I've done the same with other upstreams that for example had a minor
release to support a new RedHat version without any changes besides
that. Didn't find that to be too much of a burden.

> In the perfect world, all our transitions will be made in the future
> using binNMUs, but mistakes happen.
>
> But again, this is not something OCaml-specific, not having debian/
> dirs in packages which are not Debian-specific is a discouraged
> practice. It will strike back.
>
>> 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?
>
> Have a look at our scripts, and mimic what they do. They are in our
> svn: project/git-guide/new-d-o-m-git-repo (waiting to be shipped
> within dh-ocaml).

Will do.

>> > 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.
>
> No it is not. Git is explicitly designed around branches and around
> not having the hassle to maintain the way you used to maintain then in
> CVS or SVN. You will just have to maintain 1 branch and from time to
> time sync it with the other.

I edit something in the upstream branch. For that I write a changelog
entry and possibly remove the item from the todo list. Then I commit
that.

Now I edit the debian/changelog to bump the debian version with an
entry of possibly just "Merging upstream" and commit that. I can't
keep the debian version the same as the released package. That would
just get me confused.

Last I merge, build and use.


With 2 branches upstream changes become more work. Correct me if I am
wrong but the problem is that the "from time to time" you mentioned
above is for every upstream change I do.

Maybe once the bindings are complete and stabilized things look
different. But currently a native package looks way simpler.

> Cheers.

MfG
        Goswin