Thanks to Reed, I just put up my latest pet project up on the l10n server.<\/p>\n
It’s offering a new web interface for buildbot builds. It does so by feeding the status data that buildbot has into a database on the one end, and on the other end is a django app displaying that data.<\/p>\n
The nice thing about this is that writing features (or fixing bugs) is “just webdev”. Compared to whatever you want to call tinderbox hacking.<\/p>\n
There are already a few concepts demoed on the site. All urls are in flux, note the “stage” in them. But the principle should be obvious.<\/p>\n
Firstly, you can get to a regular waterfall on waterfall<\/a>. Yes, there are some time-sorting issues there. But it’s quick, which is cool. Compare it to the regular buildbot waterfall<\/a> (didn’t bother checking which timerange that shows). And it offers a nice compromise (IMHO) for displaying detail or not. For finished builds, it shows one box per build. For builds in progress, it shows a box per step (it doesn’t show a box for the build for those steps, which is confusing). It has a blame column, too. Whenever you see a change number, that links to a new page, which lists all builds for that particular change. This one<\/a> shows an en-US check-in with all locales turning red, for example. Another one<\/a> just shows how things go green for Arabic again, as that localizer checked in.<\/p>\n For the l10n builds, that’s peanuts, but if you’re landing on a tree with real compiles, being able to follow all builds for your landing, and no others sounds cool.<\/p>\n And django comes with helpers for generating feeds, so creating a meaningful live bookmark to follow your own landing doesn’t seem like an unsolvable RFE.<\/p>\n There’s more. You can restrict the waterfall to only show builds for a particular slave. You can restrict the shown builds to only show builds with a particular property, say, the Macedonian builds<\/a>, compared to all builds<\/a>.<\/p>\n