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 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
