openstack team mailing list archive

[Monty Taylor <mordred@xxxxxxxxxxxx>]

On 08/24/2011 10:22 AM, Thomas Goirand wrote:
> 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.

Great. Things that are standard make me happy.

> 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.

This is one of the things we should discuss. I was talking about adding
the packaging branches to the main repo - so master would be the actual
VC used by the project devs. It would look like:
  master - main development target
  pristine-tarball - pristine-tarball diff information
  upstream-* - packaging 'upstream branch'
  debian-* - debian packaging branches

I could be swayed either way on this, but I think there's something to
be said for having it all in one place.

> 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

I'd much rather use git-buildpackage. It's solid and standard, which is
the thing I'm going for here. "cool" is not interesting to me -
something that lots of people can clearly understand how to use is.

>> 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... :(

Sorry - I should indicate here. (forgive me if I sound snarky) - I don't
really personally care about backports.d.o - it's the backported library
packages that go into the openstack repo I care about.

BUT - I may have been unclear here - I think there should definitely be
a repo and it should match the standards above, I just don't think it
needs to have a branch that's related to upstream VC.

Monty