[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