[Debian-ha-maintainers] shared Git repository layout

Tue Apr 14 16:47:42 UTC 2015

On Tue, 2015-04-14 at 13:01 +0200, Ferenc Wagner wrote:
> Richard B Winters <rik at mmogp.com> writes:
> 
> > I've updated/migrated your improvements to the debian branch after
> > reviewing them. Thanks again for having taken the time -> I've noted
> > each of your changes, and recall why you suggested them.
> 
> Hi Richard,
> 
> Looking at http://anonscm.debian.org/cgit/debian-ha/libqb.git/, looks
> like we still aren't quite on the same page regarding repository layout.

No we are :), I've not finished setting up the repo yet; I was waiting
on you to figure out about your changes. The repo will be finished
shortly now that I've got your response.

> Before I go into the details: why did you prefix your commit messages
> with ####s?  

It's an old habit, because they are formatted in pull requests (if there
are single commits it pulls the title of PR and body from the commit
directly)...I _will_ stop with that :)

> And I don't think gbp patch-queue branches should usually
> be published at all, as they are rebased frequently.

No probably not, but please allow me to explain:

- The upstream branch was created as follows:

1. git checkout --orphan upstream
2. git pull upstream/master
3. git reset --hard 3f7de65 (resets to latest release commit based on
release tarballs commit hash)

So as you can see upstream is a fork of the real upstream with all of
it's history.

The next step is to create the main debian branch...

1. git checkout --orphan debian
2. copied debian directory into branch after deleting all files staged
in commit.

you can't make a branch with a '/' in its name...so you make a main
'debian' branch..then branch the other branches when necessary (i.e.
debian/sid etc). I simply haven't needed to do that yet.  I can branch
from the current debian into debian/sid in a matter of seconds when we
want - anyone of us can.

The next step was using 'gbp-pq' to import the patches into separate
branches, importing your patches into branches let's us now easily offer
up those patches for cherry-picking to upstream.

And the last step, is to prep the master branch for packaging work:

1. git checkout upstream
2. git checkout --orphan master
3. git add .
4. git commit -m 'Initial upstream import'
5. git read-tree --prefix=debian/ debian  (this gets the debian branch
read into the debian directory in master)

Now we can work in master until the package is ready, then we create a
tag for master.

Another thing I should have done ahead of time, was to create a v0.17.1
tag for the upstream branch commit used for the release (which is the
commit used for the upstream release tarball). This I will do.

> > I added your changelog notes to my changelog
> 
> The usual format for multi-author changelog entries is:
> 
> package (version) distribution; urgency
> 
>   [ author1 name ]
>   * change 1
>   * change 2
> 
>   [ author2 name ]
>   * change 3
>   * change 4
> 
>  -- maintainer name <email address>[two spaces]  date
> 
> We can also think about using git-dch, but I lack experience with it.

Perfect, that's what I needed to know :)  Yes, we now have also
'Formorer' and 'Myon' helping us out. Both are DD's who can upload. 

Formorer said he will help coach me in the new packaging methods
(including using git-dch). He'll also help with uploading and perhaps
some packaging where needed.

Myon said he'll mostly be helping with uploading.

Both have been chit-chatting with me in #debian-ha, I'd recommend
everyone start sitting in there so we don't have to make a 'to-do' list,
though the guys did suggest making a wiki page for that.

> > I'm going to merge the updated debian branch into master, and apply each
> > patch in the series one at a time and then offer the fixes upstream
> > (where applicable); that is, unless you've already done so?
> 
> I haven't yet.  And here is one reason to package in the forked upstream
> repo: we could just create a branch (like the patch-queue branch without
> the non-git-version.patch starting at current master) and create an
> upstream pull request for that.

All we have to do is make the pull-request, I'm rather certain that is
why gbp-pq import exists.

> So, to achieve this (now going into DEP-14), we have to start by cloning
> (forking) the upstream repo with its full history.  

Done as explained above

> For easy reference
> and cherry-picking, leave the master branch tracking upstream
> development, do not merge Debian changes into it.  

All the guides I've read suggest master has debian/<whichever package>
merged into a sub-directory called debian. It is also how importing the
tarball sets up the branches.

> We want to base our
> packages on upstream tarball releases, though, so we need an upstream
> branch and import the releases there.  

I don't like this, if we're forking upstream I don't want to do
this....this seems extremely pointless. I believe we should choose 1 or
the other....work off of the tarballs only, or work off of the
repository and let the git tools recreate the tarball from the
repository alone.  Honestly this will fix our issue with needing the
tarbal-version file for properly building on debian...since we have
the .git directory now during the build.

> We also want to be able to
> regenerate the upstream tarballs from our repository alone, thus we need
> a pristine-tar branch as well.

I think using the repository, and the specific commits used for the
tarballs is enough, especially if we'll also leverage this pristine-tar
branch (which should be automatically created by the git tools no?)

>   The packaging work should be done on the
> debian/sid branch (not simply debian, to gain uniformity when we'll
> later have to do backports, stable updates or experimental uploads).
> Thus the debian directory will only be present in the debian/* branches.
> Tools like git-buildpackage can be configured for this convention.

debian/sid is a child of debian...you can't have a '/' character in a
branch name...hence create debian first -> as this is a new repository
package and a fresh start...once its ready for unstable, I'll create the
sid branch off of the debian branch.  It will happen...just not there
yet.

> 
> To be honest, I've got very limited experience with this layout, but I
> can see how this would be better than the more conventional layouts I've
> got more experience with.  That's why I recommend the above.  

I agree, I like the layout as well, but I don't like doing all that
extra work (using upstream clone _and_ importing release tarballs).

> Could you
> please enlist me (wferi-guest) into the Debian-HA Alioth project?

Absolutely will be done minutes after I reply.

> I'm willing to start up the libqb repository if you prefer.  

I want to learn this, and get it down. If its ok I'd like to be schooled
until I have it right :)

> I'll also
> reshape (or replace) the corosync packaging repository into this form.

Beautiful, it'd be nice if everyone would reshape or replace the package
they are workin on in the same fashion. Would really like to see
uniformity and standardization in our practices.

> Also, the debian-ha/debian-ha unused repository should be removed, I
> guess.

Not sure if it's needed or if deleting it will mess up Alioth's VCS
link/display sytstem. When you visit vcs from Alioth it expects there to
be a repository based on t he project (debian-ha). If it's missing we
might get the 'invalid repository type' error instead of seeing the vcs
output. 

It was there before I touched anything, so I just left it right alone :P

Thoughtsj/Feedback?  I'll finish _shaping_ (borrowing your term) the
repository and ping back.

-- 
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/7dd798b4/attachment.sig>