At work, we have a bit of a vested interest in the
Puppet and
Facter packages
that are in Debian, because we ultimately consume them in Ubuntu.
We noticed that what was in Debian unstable was lagging a bit behind what
was released upstream, and when one of my co-workers tried getting in
contact with the Debian developers that were maintaining the Puppet package
and got no response, I got involved.
I got in touch with Micah Anderson and got myself and
Nigel Kersten added to
the Alioth project for
Puppet.
Despite
Jamie Wilkinson being
listed as the maintainer of the
facter package in Debian, he
claimed this was news to him, and
Matt Palmer, who was listed
as an uploader, didn't really claim much knowledge of maintaining the
package either, so we took that as blessing to take over that package as
well.
This is where the fun begins.
I've been meaning to try out
Git ever
since
Debconf 7, where all the
cool kids were using it and raving about it.
I've been meaning to make the Debian DHCP package
collaboratively-maintained, and use Git for the revision control, but I
haven't quite gotten off my good intentions and done it yet. Part of the
problem is not knowing exactly what workflow I should use, and suffering
from paralysis by analysis, reluctant to experiment, because I don't want to
go down the wrong path.
Anyway, this is about Puppet, not DHCP. The Puppet package, as it turns out,
is
already
maintained in Git on Alioth, so the problem here was more one of
figuring out what the current workflow was, and trying to follow it.
This is where Nigel came in. Conveniently, the upstream Puppet development
is done in Git also, and Nigel is a contributor to Puppet upstream, so he
had some Git-fu. So between the
instructions
on how to get started with Git on Alioth and what he knew, we could
start fumbling around.
It seems like the Alioth Git repository was also tracking the upstream
Puppet repository, as there were commits in the Alioth one by Luke Kanies,
and we didn't really imagine that he was doing Debian-specific stuff.
Here's what we ended up doing to try and get what was in the Alioth
repository up to the upstream version 0.24.8 of Puppet:
git clone ssh://apollock@git.debian.org/git/pkg-puppet/puppet.git
This part was fairly straight forward. Clone what's in Alioth locally.
git remote add reductive git://reductivelabs.com/puppet
git remote update
git fetch --tags reductive
Next, we added a remote branch that tracked upstream. We called it
"reductive", and we updated it. The bit that took some fiddling with was
fetching the tags. Nigel later figured out that tags are inherently private
to a repository, and normally stay that way. So if I have a local clone of
say the upstream Puppet repository, I can tag it to my heart's content, and
normally those tags would stay in my local repository, because they're
probably only meaningful to me.
git checkout -b upstream/0.24.8 0.24.8
This bit took a bit of work to arrive at as well. What we wanted to do was
create a new branch called
upstream/0.24.8, which was at what was
tagged
0.24.8 in the reductive repository. Nigel pondered what
would happen if you already had a tag or a branch called "0.24.8" before you
added the remote repository. This is also why we had to fetch the tags from
the remote repository, so we had something to check out.
git checkout master
git merge upstream/0.24.8
Next, we switched back to the master branch and merged the contents of our
local upstream/0.24.8 branch that we just created. This now got the Puppet
source in the master branch up to what was released as version 0.24.8. (and
this is better than just running
uupdate?)
We did some fiddling with the
debian/control file and
debian/changelog and fixed up a few things that
Lintian
was bitching about, and were done.
I'd set up a sid chroot with
cowdancer previously, and had to do
some faffing around with
git-buildpackage to convince it to use
pbuilder. I ended up using
git-buildpackage --git-builder="pdebuild --debbuildopts '-i\.git -I.git' --basepath /var/cache/pbuilder/base-unstable.cow"
So now we've got most of what we want to ship checked into Git on Alioth. I
have no idea if we've done it "right", I suspect we may have done something
wrong by operating on the master branch. Looking at the revision history in
the Git repository on Alioth, it looks like previously things have been done
a few different ways. I certainly want to write up a definitive workflow
once we've figured one out.
We haven't uploaded the new package to unstable yet, because we're still
trying to give it a modicum of testing, and we'd like to sort out the Facter
package as well.
The Facter package was a more greenfield exercise, as while there was
already a Git repository on Alioth for it, it was empty. So Nigel had to do
some futzing around to get it checked in the right way to make
git-buildpackage want to build it. He did this by himself, so I'm
not sure exactly what he did. I've since discovered that it's probably
lacking some dependencies it needs, so that'll need to get fixed before it
gets uploaded.
I look forward to reading blog posts from the smart people who actually know
how to use Git properly, telling me how we should have done it.
I'm still very interested in coming up with a proper workflow for preparing
packages and committing the changes, and for doing code review.