openstack team mailing list archive

[Thomas Goirand <thomas@xxxxxxxxxx>]

Hi Monty,

I've been quite pleased to read your mail. Thanks for that.

On 08/24/2011 11:56 PM, Monty Taylor wrote:
> This deals with:
>  - Lack of Debian support.
>  - PPAs are Async.
>  - Not integrated with CI.
>  - Lack of RPM support.
>  - PPA Fragmentation.

If I may add as well my personal view on it. It's just my 2 cents, and
my view on it, nothing so important, especially that I haven't been
involved much in the development/packaging of Openstack yet.

IMHO, there's an issue with things not being built in SID indeed. I've
been struggling to build Nova in SID. Cactus doesn't build anymore at
all. Diablo does if you build with the docs and the unit tests, which
obviously isn't what we want (and I wouldn't upload like this). There's
(pardon me) shitloads of errors printing on the screen when I build, and
it's scary. Sorry, I didn't work on it much yet (since I'm currently
working on packaging Xen API and other stuff, which at the end will
benefit Openstack too), but sooner or later, I'll go back to it.

As I understand it from a distance, this happens because SID is evolving
at a different pace than Ubuntu. To upload Cactus in SID, I had to wait
for the correct timeframe, and the window was very short where Cactus
could build. But at the end, in SID, we're seeing a technology preview
of the issues we're going to face sooner or later in Ubuntu. So we'd
better face the issues directly, no?

Also, if Rackspace is using Debian, I guess they are using the current
stable (Squeeze) in production. If so, then they are doing Squeeze
backports. That's what I've been working with too (I'm running a Squeeze
backport of Cactus). Then why aren't we sharing the efforts here, and
have OpenStack's built being uploaded to backports.debian.org for
everyone to use? I can see a silly duplication of work here that could
save time for everyone. FYI, my Cactus backport for Squeeze is at:

http://ftparchive.gplhost.com/debian openstack main

which sux too...

> I'm suggesting:
>  - we move all packaging to git
>  - we manage it consistently via git-buildpackage

Definitively, using git-buildpackage is a time saver. Having the
packaging and the "upstream" sources in the same Git tree, and being
able to switch from one to another is very convenient! It also forces to
have a really working clean Makefile target.

> As Thomas Goirand suggested, we will add a packaging branch to the repo
> of each of our projects and have git-buildpackage do the right thing. We
> can have gerrit set different ACLs for the packaging branch so that a
> different set of folks (the packaging team) can handle the reviewing of
> that branch. Combining this with a pristine-tar and having Jenkins push
> some tags back to the repo on package release, it means that we can
> trace any release of software back to our code repo, and that only the
> repo is needed to re-create any particular release.

If I may suggest... In many Debian packaging team, we use the following
naming scheme for the Git branches:

- upstream-sid
- debian-sid
- upstream-lucid
- debian-lucid
- upstream-squeeze
- debian-squeeze
- upstream-squeeze-backports
- debian-squeeze-backports

This isn't carved into the stones of the Debian policy manual, but it's
nearly a standard that many DDs are using.

Just for the sake of example (no offense I hope, to name the obvious),
if you want to build a Squeeze backport, you'd just do:

git checkout debian-squeeze-backports
git-buildpackage --git-upstream-branch=upstream-squeeze-backports \
	--git-debian-branch=debian-squeeze-backports

The branch named "master" is to be avoided because it doesn't express
anything at all.

Also, if you don't like git-buildpackage, there are alternatives, like
the "git-stuff" package from Daniel Baumann. It might be a bit too
experimental and has no documentation, but it's quite cool. Just adding
a tag to a branch does:
- Create the debian/changelog
- Builds
- (eventually) uploads

> Having branches on top of upstream source is almost useless here, as in
> most cases we're doing one-off backports.

Unless I didn't understand what you mean by "one-off" (please elaborate
so that we avoid confusions), if backports are to be uploaded to
backports.debian.org, then we'd better take care that they are
maintained correctly. So having a branch for it sounds like a
requirement to me. I wouldn't take the responsibility to upload to
backports.d.o if we don't take it seriously. I'm already feeling quite
bad that I've left the current packages in the air without fixes, with
the build process totally broken... :(

Again, that was just my 2 cents...

Cheers,

Thomas Goirand (zigo)