{changes}
{local check}
hg commit
hg push
{remote check}
{remote build}
{d/l and check}

Tinderbox gets me the remote check and shows me the build has happened (and if anything’s gone wrong), but it’s hardly streamlined.

You’d get super-awesome bonus points if I could look at the hg changelog on the web, and click through to the results of a compile and the downloads from it. How hard that would be, I don’t know.

I like waterfalls for particular aspects, in particular as a kind of activity monitor. But they fall short in tons of aspects, which is why they’re not the sole truth.

preed, we had a few discussions on build web interface wishlists so far, and they sadly showed that people don’t know what our builds look like. I only referred to the chromium waterfall to give those some hands on experience that we had for years now, so that they can get on the same page. I have no intent to suggest that we go for that web interface, nor its underlying arch.

* Buildbot doesn’t have any sort of scalability; you’d better hope twistd can handle the http load.

And if it can, you’d better hope it doesn’t crap itself in a way that causes it to lose connections to the slaves… because you know what that means: failed builds!

* Buildbot has no authentication. When some kiddies decide IRC isn’t enough and it’s time to annoy everyone by constantly forcing builds, stopping them will involve blocking pages you probably care about.

Add a .htaccess file? Oh right, this is twistd, not Apache.

Not many people will defend tinderbox, but there’s a reason it’s been around for so long.

It would be good to see people address these problems, instead of handwave about why they aren’t actually problems.

It’s interesting to me that for all the buildbot fanboys, people still seem to think the waterfall is a bad way to represent build data… except, they ignore the fact that buildbot’s only representation of that data is (still themes on) a waterfall.

- A central place to set tree status and have that information pulled.

You touched on this a bit, but I’ve really been thinking about this for comm-central – we have 3 apps using one repo, and we need a central place to set tree status and notices – not just for that repo but for the apps that are there, i.e. we sometimes close TB but leave SM and calendar open.

Of course, other extensions/UIs need to be able to pull this information as well.

- An indication of how long it will be before my changeset gets built.

How long before the builds will start, how long do the builds running have left.

I realise an ETA is hard to calculate, especially with clobbers or size of patch, but it can help to know roughly when to check back on the tree, rather than being glued to refreshing the web page all the time.