One of the things that was pounded into me while working at MoCo is the
idea of having a bug tracker and using it. I literally can't work
without one anymore. It's the first thing I really pushed for at my new
job (they were using various ad-hoc systems for …
Looks like the openSUSE build service can package up your software
for a bunch of different Linux distributions, cross-compile, track
upstream project dependencies (e.g. rebuild your GTK app when GTK
changes), and runs on their servers so you don't have to maintain the
thing.
I put this set of slides together to explain what state the release
automation project is in. It probably makes more sense when I am sitting
there to explain what each point means, but I figured I'd put it out
there anyway :)
As previously announced on Tinderbox and planet, we're migrating nightly
production to running on the same machines as release production.
On the moz1.8 branch, we've been running the new nightlies in parallel
with the "traditional" nightlies since Feb 15 2008, and are going to
switchover live tomorrow.
I've set up the release automation staging server for the Mozilla 1.8
branch (Firefox 2.x) to also generate nightly builds and depend builds
on checkin to the branch (using buildbot's BonsaiPoller). I outlined
some of the advantages to this release automation/nightly+depend
integration in my previous post …
As I mentioned previously, I've been working on incrementally moving
our Tinderbox client installs over to Buildbot.
The first step is to switch from driving Tinderbox from Buildbot and
our release automation system, instead of being driven on each
machine from the multi-tinderbox script. The release automation still
calls Tinderbox …
I've started working on migrating the Firefox nightly builds to use the
same release automation system that we've been developing for the
past year or so for maintenance releases (Firefox and Thunderbird 1.5.0x
and 2.0.0.x). The reason this is important is that each nightly release …