[Debian-ha-maintainers] shared Git repository layout

Ferenc Wagner wferi at niif.hu
Tue Apr 14 11:14:36 UTC 2015


Richard B Winters <rik at mmogp.com> writes:

> 1. Upstream branch is fetched from clusterlabs, and reset to the release
> commit of whichever release we are packaging.

What do you mean by 'fetched'?  It should be imported from released
tarballs, but then what does 'reset' mean?

> 2. Debian branch contains the debian directory contents, if there is a
> difference for different releases (i.e. jessie, sid, experimental) in
> the debian directory then we would create those specific branches using
> the main debian branch as the reference.

I'd start up with debian/sid from the beginning for uniformity's sake.
It's mainly a matter of preference: the shorter name does not buy us
much, but makes the layout less obvious.

> Since all the new packages we're creating will eventually be on jessie
> and sid -> I've only included a single debian branch.

We can (and surely will) add more packaging branches as backports or
stable updates necessitate it.

> 3. When the master branch is as desired for a release, we create a tag
> for the commit as for reference of the release, and a tag for our
> upstream branch for reference of our release as well (or is that not
> necessary?).

As explained in my other mail, you don't release from master in a DEP-14
scheme, you tag the appropriate debian/* branch instead.  Tagging the
upstream branch happens at import time.

> 4. We are not importing release tarballs, so we are not using a
> pristine-tar branch. Why would we keep an upstream clone of the release
> commit in our upstream branch, plus import the tarball into
> pristine-tar?

We import release tarballs and want to recreate them, thus we need the
upstream and pristine-tar branches.  These are not strictly necessary,
but the conventional Debian workflow is based around pristine tarballs,
so we'd better play by the rules.
-- 
Regards,
Feri.



More information about the Debian-ha-maintainers mailing list