(No comment was entered for this change.)

While complex, this would be a pretty cool feature to have. I'm not sure if Review
Board is the best place to put it, but I haven't thought it through too much. It
would be nice to have some sort of buildbot/sandbox integration that has a simple
status field on the review request header saying "This builds." or "This fails."

+1 (Googles Issue Tracker lacks support for votes..)

This was _the_ feature I was/we were looking for in patch management/review systems.

In order to accept and apply a patch you want the following to hold:
1) The patch follows any coding guidelines decided upon
2) The design and workings of the patch are satisfying
3) The patch should not break existing code

When doing manual code review you want to focus on functionality and design - 2)
above. Minimizing everything else (in the code review) is in my opinion a big win. 1)
and 3) above can (in many cases) be automated:
1) -> Lint,Hammurapi,Checkstyle,...
3) -> BuildBot,CruiseControl,...

Since Review Board is supposed to cover the whole review process (as opposed to these
other tools), it would be very beneficial to be able to at least see the status of
the outcome of tools like that.
Imagine UI labels as:
"This patch follows coding guidelines"
"This patch breaks rule 12.5 of coding guidelines. See report _here_."
"This patch builds and has passed all tests on all platforms"

Then you would have providers to create these labels, since each tool is different
(just as the SCM tools). The provider would need to know where to fetch the result
from any job (i.e. build or lint-run), and how to display it. To actually run the job
would be the complex thing here (and out of the scope for review board).

I didn't look at the database scheme for review board, but I reckon it could involve
adding some states to a review or attributes to a patch - like "BUILD_PENDING" or
"CHECK_SUCCESSFUL". Well, now I'm just imagening. Better stop there and call it my 2
cents..

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

Hudson (and presumably other continuous integration systems) makes it very easy to
have builds trigger pokes of other systems.  Thus there is an integration with JIRA
that puts a comment on all bugs in the change list of a build.

Hudson also handles patch builds well.  Apache projects use this extensively by
arranging for hudson to scan for issues that are in the "patch available" status. 
Hudson then downloads the patch, checks out the code, applies the patch and puts a
comment back on the original JIRA issue.

This structure could easily be adapted if there is a simple way for an outside system
to scan for new reviews and a simple API for posting comments.  The build system
could then sift through the reviews eliminating those it has already seen or which
refer to code not under a build watch.  Any new qualifying builds would then be built
and a summary posted.