[Debian-ha-maintainers] shared Git repository layout

[Richard B Winters]

On Tue, 2015-04-14 at 13:14 +0200, Ferenc Wagner wrote:
> 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?


git fetch/git pull.

Resetting the upstream branch to the specific commit that was used to
create the release tarball. If we're using upstream's master as the
upstream branch (for all the history), then we should be working this
way.  We'd tag it for easy reference later on because we don't have
their tags.

The git tools will also handle creating the pristine-tar in this
fashion, so I don't see why I should be importing the release
tarball...if this was the case -> my last repository was just fine...so
why am I doing all of this? Because you said you would like me to fork
upstreams code.  There is not a single guide suggesting to fork
upstream's entire repository (branches and all), and work in the master
branch after....they all suggest to 'pull' upstream's master into the
upstream branch and reset it to the commit used for the tarball...tag
it...and merge it into master.


> > 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.

debian is simply the father branch...sid, jessie, experimental; all are
branches created from debian initially....hence the
debian/<codename>...all I have to do is branch debian into sid, then we
have debian/sid.  You cannot put a '/' character into a branch name (I
tried).


> > 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.

Yes, I meant for now (as an explanation for why you won't see: jessy,
sid, experimental, backports, etc....as child branches of debian/ until
you've approved the release and its necessary.


> > 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.

All the guides explain that when you're ready to make the package,
debian/* and upstream are merged into master...master is where you make
your changes to the source, where you build, test etc. I can totally
understand what you're saying...all the debian/ work happens in the
debian branches...then are merged into master. 

That's not always realistic though, you'd have several merge commits on
top of master, and each time you want to 'read-tree' again you have to
remove the previous contents...because read-tree with --prefix will
_not_ overwrite anything _ever_.

BTW, that's exactly how importing a tarball works as well...it creates
the debian branch, the upstream branch (tags it yes), and merges both
into master.

If you import the release tarball...but I'm not doing that -> I just had
that all setup previously... I don't see the need for an upstream fork
into upstream branch if we're importing tarballs...importing a tarball
overwrites the contents of the branch its imported into....not really
making any sense into me....that's what pristine-tar is supposed to be
for...no need for an import.


> > 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.

I think I'm gonna just have to say have at it, please write up a guide
for the rest of us to follow, because this just seems too contradictory
to me.  Why import the tarball if upstream branch is a clone of
upstream?  Importing the tarball would overwrite its contents and it
wouldn't be a clone of upstream anymore.


Please advise,



-- 
Rik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/debian-ha-maintainers/attachments/20150414/e8d9c614/attachment-0001.sig>