Open Stack

On 02/11/2013 03:27 AM, Monty Taylor wrote:
>> And also: we don't use release tarballs in Debian, just the tags.
> 
> Interesting. I'd like to discuss your workflow at some point.

Let's do that now if you like: let me explain! :)

First, it's described here (but not in details):
http://openstack.alioth.debian.org/

That doesn't describe all though. For example it doesn't tell how to
actually upgrade to a new version. In fact, it's rather easy. Here's how
to upgrade from 2012.2.2 to 2012.2.3:

git clone ssh://git.debian.org/git/openstack/nova.git
cd nova
git checkout -b debian/experimental origin/debian/experimental
./debian/rules get-vcs-source
git merge -X theirs 2012.2.3
# Solve eventual merge conflicts and commit that...
dch -i # Edit changelog and write 2012.2.3-1 as Debian version
./debian/rules get-vcs-source

The get-vcs-source will:
- Do: git remote add upstream $(UPSTREAM_GIT) if it's not in the local
repository already (this $(UPSTREAM_GIT) variable is either set to
git://github.com/openstack/$(DEBPKGNAME).git or forced for each
individual package if they aren't hosted in the openstack username at
github).
- "git fetch" and "git checkout -b" upstream master branch
- create the .orig.tar.xz from the tag, according to what version is
written in debian/changelog (using "git archive").

The good point is that this way, I can just tag any commit, push the tag
to alioth.debian.org, and generate the corresponding orig.tar.xz. That's
how we have python-swiftclient 1:1.2.0+git1.2be776c2-1 currently in
debian experimental (we needed some new functionality from it at the
time, I probably should now upload 1.3.0 ... but this was just an example).

When we have a tag like "grizzly-2", since that corresponds to nothing
like the Debian versionning scheme, I retag it like this:

git tag 2013.1_g2

then in the debian/rules we have:
GIT_TAG         ?= $(shell echo '$(VERSION)' | sed -e 's/~/_/')

so that 2013.1~g2 can be transformed into 2013.1_g2 (because
unfortunately, git doesn't like the "~" char...). Then I push this tag
into Alioth.

Note that at no point, we store the master branch of any package in the
Alioth git repository. These are always fetch using get-vcs-source,
directly from github. Why do we do this way? Well... because we can! :)
More seriously, because there's no point to have a copy of the master
branch which we would have to constantly sync from upstream repository,
so it's more convenient to just always sync from the "upstream" remote.

Then, I simply do:
git-buildpackage

and ... that's it! If it doesn't fail to build, the result will be in
../build-area (thanks to what's configured in debian/gbp.conf).

If there's anything more you need to know about the above (or about
what's *not* in the above), please ask.

What *I* would like to make sure of is:
1/ what's the *official* way to generate the MANIFEST.in out of git?

For the moment I do:

git ls-files --no-empty-directory --exclude-standard
$(MANIFEST_EXCLUDE_STANDARD) | grep -v '.py$' | grep -v LICENSE | sed -n
's/.*/include &/gp'

with MANIFEST_EXCLUDE_STANDARD being equals to nova, cinder, glance,
keystone, quantum, etc. (in fact, the Debian source package name). Is
this correct? Or will I miss some files doing this way? IMO, it would be
nice if generating a correct MANIFEST.in was part of tagging a release.
I only very rarely package any random commit, and I generally don't feel
really safe generating the debian specific patch for that.

2/ Do I need to set the OSLO_PACKAGE_VERSION variable according to what
I have set in the debian/changelog (which, thanks to a bit of
dpkg-parsechangelog in /usr/share/openstack-pkg-tools/pkgos.make equals
to "VERSION")?

3/ Do I need to set the "versioninfo" file to something manually? It
seemed this file is sometimes at the root, sometimes in
tools/versioninfo, I'm not sure where to generate it... And if I use the
OSLO_PACKAGE_VERSION variable, do I still need to tweak the versioninfo
file? What is this versioninfo file for anyway?

I know these have been discussed, so I'm sorry in advance for asking
again... I really do feel I'm a pain in the back on these topics, but
this is still not 100% clear in my mind. :(

Thomas Goirand (zigo)