[Buildbot-devel] database-backed status/scheduler-state project

[exarkun at twistedmatrix.com]

On 06:28 pm, bhearsum at mozilla.com wrote:
>
>On 2009-09-08, at 2:20 PM, Brian Warner wrote:
>>
>>>At least, not unless you're willing to break whatever third-party
>>>code
>>>is relying on the API. I would definitely want to avoid this. The
>>>idea
>>>of actively seeking it out is almost painful. :)
>>
>>We could take this road, and put a warning sticker on the db schema
>>that
>>says "subject to change, you take responsibility for updating anything
>>that you write that touches this, we will not bend over backwards to
>>retain compatibility with your apps". Or we could take the other one,
>>with a granite plaque that says "we promise to never ever change this,
>>use it with confidence". Or something in between.
>>
>>I guess I'm (currently) comfortable with the warning sticker approach,
>>under the theory that the minority of users who need to build these
>>sorts of tools (and are willing to get their hands dirty) will also be
>>willing+able to pay attention to the schema changes from one release
>>to
>>the next. Most users won't be aware of the db.
>
>I think this is totally reasonable, and to be expecting from a piece
>of software that hasn't claimed to hit 1.0 yet. Despite being integral
>to many, it's still Use At Your Own Risk IMHO. And as you've stated
>below, there are comparable things that have happened elsewhere in the
>code base. I certainly don't think the first release with this would
>be the right time to freeze the interface.

I think this is problematic for a couple reasons.

First, Buildbot is always going to be Use At Your Own Risk.  Very, 
little software is anything else, particularly software developed by a 
loose group of individuals with no major assets to take in a lawsuit. ;)

Second, the idea that someday a point will be reached where people are 
going to *stop* having interesting new ideas and *stop* wanting to try 
out crazy new approaches to build automation is a pretty tenuous one. 
Are all Buildbot users and developers going to wake up one day and think 
Buildbot is done?  It's rarely the case that you have even *one* person 
come to this conclusion. :)  So, if you buy that, then it makes sense to 
*always* be trying to mitigate the negative consequences of ongoing 
development.  That means striving for compatibility through the entire 
development of the project, not just after some arbitrary milestone.

I realize there is a cost associated with maintaining compatibility. 
Unfortunately it's one which is quite difficult to actually measure. 
Likewise, the cost of breaking compatibility is also rather elusive. 
The perception of these costs is often skewed by perspective, as well, 
since the cost of compatibility is largely on the core developers and 
the cost of incompatibility is largely (but not completely!  Brian's 
point about Buildbot itself needing to be able to load older versions of 
its own database is an important one) on the user base.  To me, there's 
little question that for a project of Buildbot's popularity, the costs 
of compatibility are easily outweighed by the costs of incompatibility.

Jean-Paul