[Buildbot-devel] the aftermath (was Re: SF bay area get-together?)

[Robert Helmer]

This was a good time, thanks Brian for putting it together and thanks to
Mozilla for providing the space (and to everyone who brought beer, etc :) ).

I will do a blog post at some point soon, but I thought the ideas discussed
sounded very promising so I wanted to get this back to the list first.
Here's what I remember (I had to leave a little early), maybe others can add
or remove:

* using sqlite as backend (instead of current pickle-to-file method)
** brian has some work on this in a darcs branch, to be published?
* more complete data interface than XMLRPC (e.g. JSON equiv. for every HTML
page buildbot can do)
* dedicate space on the wiki to looking at buildbot competition (I talked a
bit about what I like about Hudson, for example, a lot of which would be
fairly minor to support in buildbot)

These came up in the context of things like reporting, building UI e.g.
large status pages, etc. without having to hack things directly into
Buildbot. It seems that extending html.py and other core Buildbot classes is
very common, so people tend to get stuck on older versions (that, and config
file format changes breaking things!). Also discussed how "reconfig" doesn't
always work, how changing the way scheduling works could help. A database
for the backend might make this easier to do.

We also looked briefly at Cruise Control's reporting interface, and a custom
report that Nick Thomas at Mozilla put together using Tinderbox server's
JSON interface (at Mozilla, Buildbot reports to Tinderbox server.. queue the
"in Soviet Russia" jokes). Some UI discussion in general, e.g. waterfall is
a very administrative type of interface, developers probably want something
higher-level (e.g. "so can I check in or not"), waterfall is something you'd
drill down to after problems were known.. not sure if UI is really
Buildbot's "job", maybe better to expose database and JSON (or whatever) so
more specialized user experience type people can meaningfully contribute?

To touch on the last point a bit, some Hudson features that I thought would
be great for Buildbot to do:

* easier out-of-the-box configuration (web-based setup wizard, suitable for
very simple projects). Maybe this could help shield simple products from
config-format changes?
* explicit support for releases (tracking deliverables, after-the-fact
tagging from the web ui)
* bugtracker-integrated "try" server (just post a patch and Hudson comments
with results)

I think one of the ways they've acheived a lot of things in a short time is
through explicitly encouraging external plugins, they only ship with very
limited SCM support for example. I'm torn on whether this is a good or bad
thing long term, e.g. Linux versus Windows kernel/driver model is probably a
good analogue on the tradeoffs to this kind of thing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buildbot.net/pipermail/devel/attachments/20080725/d2f619bd/attachment.html>