Lots of stuff done this week in between release activities. I am on planet.m.o now (though too late for most people to have seen my previous post most likely), thanks to tor for setting me up!
Made some good progress on the release automation work (started tracking bug 355309). My goal was to have the framework, staging server and all basic steps implemented; I got the first two done but still working on the last. My goal for next week is to use the staging server to help test the release steps and run through a mock 1.5.0.7 release; if I can go from CVS to verified updates I’ll be a happy man.
I’ve been using SVK for this project as well as the Buildbot patches I’ve been working with; overall I really like it, my only issues are:
- Metadata in diffs caused a stir when I posted patches to Bugzilla :)
- No server to push to; I can generate patches though. Contrast with
Mercurial, which lets you easily run ad-hoc servers (more of a
convenience thing). I’d rather
vcs push some.hostthansvk push -P patch; svk patch --view patch > ~/patchand email that around. - Davel and TR both had to strip some of the metadata to get my SVK
patch to apply;
svk patch --applycomplained about CVSROOT metadata likerhelmer@cvs:/cvsroot, and they had to change that to be equivalent to what they used for their local CVS mirror.
It is an improvement over just having a CVS checkout, but I am wondering if I might as well just run a full client/server system like Mercurial, git, or monotone and keep a server on my laptop. Feel free to comment and give me some much-needed learnings :)
Speaking of much-needed learnings, Jonas helped me get over the finish line with my build-status waterfall page implemented as an XSLT (the original version is not nearly as nice, both in markup and overall effect).
This started out as an attempt at a free lunch (which is a surprisingly effective motivator, even if I would have to share with Jonas now!), however I have been working on a Buildbot status plugin in a local branch and I think doing it this way could drastically reduce the amount and complexity of code that Buildbot uses to generate waterfall pages. Also, it would be relatively simple to write an XSL to transform the same XML into other forms like RSS and microsummaries.