Another lazr package (delegates), another ITP (#758828), another chance to play with a git package regime. This time I chose git-buildpackage.
I must admit I cheated a bit at first. I started with the 2.0 tarball from
PyPI so I could test upstream updating (I released 2.0.1 earlier in the day).
I unpacked the 2.0 tarball, `cp -a`'d the debian/ directory from lazr.smtptest
into it, edited the files for the new package name, and then generated the
.dsc using `debuild -S`.
Then I `git init`'d a new local repository and used `gbp import-dsc` to
initialize the git information. That seemed to work just fine.
Now I wanted to update the package to 2.0.1, so I used `git-import-orig
--uscan` which works great, except that it doesn't add a debian/changelog
entry. That would be a nice convenience I think.
Now I had a chance to see how patches worked, since the 2.0 version had the
same setup.py bug as with lazr.smtptest, but it also had a missing MANIFEST.in
(which I adjusted for in d/rules in the initial 2.0 packaging). So here, I
wanted to get rid of the setup.py patch as it would no longer be necessary.
`gbp pq` is the tool to manage the patch branch, but there were a few things
that seemed messier than with the git-dpm experiment:
* I used `gbp pq switch` to get to the patch-queue/master branch. Unlike with
git-dpm, this does *not* delete the debian/ directory. It did make things
smoother with Emacs because upon switching back (later) to master, I didn't
have to revert the files I was visiting. But I realized that it did leave
me in a somewhat confusing state. Should I use quilt? The patches were not
automatically applied by `gbp pq switch`. Maybe I should have imported
them.
* Doing another `gbp pq switch` left me back on the master branch, but did
nothing to the quilt stack. I had to switch back to patch-queue/master and
then `gbp pq export` to get the stack updated on the master branch. In this
case, upstream fixed the bug that the patch was addressing, so like with
git-dpm, git-bp deleted the entire d/patches directory.
It makes me think that git-dpm's handling of debian/ is probably closer to
right, so that there'll be no temptation to muck about with quilt while in the
patches branch. Maybe a better approach would be to delete just
debian/patches - that would remove my confusion but wouldn't force me to
revert all the debian/ files I was editing.
I was disappointed with the documentation surrounding the `gbp pq` workflow.
It's not really described in the git-buildpackage manpage and the best
documentation for `gbp pq` is off-site and external to debian.org.
The other disappointing thing is that once I was back on the master branch,
the patch-queue/master branch was not deleted. That's a nice little cleanup
that git-dpm handles for you. After all, who wants that temporary patch
branch on git.d.o?
Finally, it was time to build the source package for 2.0.1. lazr.delegates
had a few additional tricky packaging things to handle so I had to do more
iterative testing. I.e. edit some d/ files, build the package, lintian, look
at the build log, install the packages in a chroot, rinse, repeat. One thing
I really like about our svn-based workflow is that svn-buildpackage supports
--svn-ignore-new so your source package includes uncommitted changes.
git-buildpackage has --git-ignore-new but that's actually not enough! Because
of the vagaries of git, you have an extra "level" of changes, i.e. the index.
This means that if you want to include uncommitted changes in the package, you
need to also use --git-export. There are two options here: --git-export=INDEX
obviously includes the staged changes while --git-export=WC includes the
working copy. =WC seems much more aligned with my own personal preferences,
and is closer to what svn-bp does by default.
A few other random thoughts.
git-bp includes some desktop notifications, so that I see a little bubble when
it's done doing its thing. Since I'm usually only doing a source build and
that goes by quickly enough that I'm always watching it anyway, this was just
annoying. (I'm sure it can be turned off if I cared enough.)
Once I uploaded the package, I had trouble with git-bp --git-tag-only
recognizing my gpg keys. I didn't investigate further, but just used
--git-no-sign-tags for now.
I created the repo on git.d.o like Raphael outlined previous and pushed
everything to it. As before, feel free to play with it but do let me know if
you make any changes (see below).
After this experiment, my own personal preference is leaning toward git-dpm.
It just seems like a cleaner, more self-contained, and better documented
workflow. I think there's room for improvement, but git-dpm is "just" a fancy
shell script so I hope it's maintainer will be open to patches and
suggestions.
In truth though, I bet it won't be hard to convert from one to the other. The
biggest difference that I can tell is that if you use the default branch
names, it's mostly just the tag names that differ:
git-dpm: {debian,patched,upstream)-<version>
git-bp: {debian/upstream}/<version>
I don't know if there are any DAG or metadata that would make conversion more
difficult, but if it's just renaming tags, it's probably easy to automate a
conversion process.
Anyway, I hope we can talk about this more at DC14. I'm starting to think
about some concrete proposals and a transition plan. I do think we need to
choose one or the other regime; either will probably do just fine, but git-dpm
seems like the more comfortable step for those of us familiar with svn-bp.
Two other things: the hooks that get installed in git.d.o end up sending
emails to the python-modules-commit mailing list. Unfortunately, all my
changes get held for moderator approval. I emailed the list owner and have
not heard anything yet. Does anybody here have admin privs for that mailing
list? I don't have the same annoyance with svn-bp.
We should probably also connect the commit hooks up to IRC as is the case with
svn-bp. I don't know about you, but I definitely do not want more email
traffic. Notifications in IRC are fine, more email is not! :)
Cheers,
-Barry
signature.asc
Description: PGP signature
