[Buildbot-devel] force requests under original buildset

[Dustin J. Mitchell]

So, I think you're suggesting adding build requests to a buildset
after the buildset is created.  Of course, you're free to do what you
want locally, but in general I don't think that's a good idea:
 * buildsets' status is based on a summary made when the last
buildrequest is complete.  If buildsets can be added later, then there
are all sorts of interesting questions about when a buildset is "done"
and what its status is
 * Modifying a buildset after the fact gets away from the largely
write-only nature of objects in Buildbot, which is a building block of
the data model in the data API

The problem you've identified is a real one, though, and I've been
thinking a bit about it lately.

First, what are buildsets good for?  Buildsets are the unit by which
builds are *started*, and to that extent basically only exist for the
dependent scheduler.

However, now that we have multiple codebases, buildsets also represent
the point where those codebases are tied together to select a
particular set of sourcestamps.

I think the kind of questions you're looking to answer with buildsets
are better answered directly from sourcesetamps.  However,
sourcestamps aren't very well organized right now -- there are *lots*
of duplicate sourcestamps in the database -- and some of them are
relative -- making it difficult to tease out all of the builds for a
particular piece of source code.

I think the better way forward involves:
 - making sourcestamps unique, so a sourcestampid uniquely identifies
a particular version of the code in a codebase
 - adding the right indexes to allow queries for builds for a
particular sourcestamp to be performed efficiently
 - disallowing relative sourcestamps - make them absolute at the time
they are created (requiring changes to changesources)
 - encoding extra information about the relationship between
sourcestamps in the changes table (basically, parent pointers for
changes)

I'm working on some of this (the first two points) in nine, while
laying the groundwork for the rest.  It's all on my laptop right now
(just got started a few days ago), but I should have some working code
sometime next week.

Dustin