Incompetence or Incomprehension?

Someone recently linked preed‘s rant about Buildbot to the #buildbot IRC channel. After having read through it, I feel compelled to respond to a number of points raised within it. I’ll try to keep things as neat and tidy as I can, but considering the original post is rather extensive, things may get a bit involved. As it is, I’ll refer to the various bulleted points in the original post by lettering each one within a specific numeric item, thus the third bullet under ‘2’ would be 2/c, et cetera.

“Er… You Can Do That.”

There are some things that seem to stem from a lack of knowledge about certain parts of Buildbot (or perhaps out-of-date knowledge?):

  • 1/d – Buildbot does allow password protection of the administration interface. See the Authorization section of the WebStatus configuration options.
  • 2/c – If you want to set a property at runtime try SetProperty – and if that doesn’t meet your needs, just write a BuildStep to do it. You have all of the flexibility of Python to do it with.
  • 2/g – Buildbot doesn’t force this upon you. What’s to stop you from instead describing your build process as say, Makefile targets, and then simply having each Buildbot step invoke a different target? Buildbot aims to be generic, and thus requires some form of comprehending a build process; the other option (of trying to hard-code understandings of various existing build solutions) sacrifices a huge amount of flexibility.
  • 3/a – The port(s) used by Buildbot are completely customizable. If all you can have open is port 80, then you can configure Buildbot’s master to run on port 80. Slaves don’t need a port open. (If you can’t have any ports at all open on both the master and the slave, how do you expect to have a network-distributed build system operate in the first place?)
  • 3/d – So far, I haven’t seen any patches that were submitted and ignored, and quite a few patches have been submitted and accepted. Not only that, but there are more people than just the ones who work at Mozilla who have commit access to the official repository – you’re reading the words of one of them. Paranoia helps no one here. If something is “being neglected” there’s nothing to stop attention being paid to it by anyone who’s interested in that particular area. In fact, I’m fairly sure the maintainer has been looking for more core contributors!

“It’s On the List”

Other points raised have some validity, but they’re also things that the Buildbot project has known about for a while, and is actively looking to fix. Considering that most of the contributors have jobs that include more than just Buildbot, changes take time, but that doesn’t mean things are being ignored:

  • 1/a – There have already been attempts to address slave connection loss. So far, the complications seem to stem from properly hooking up the right status/state to the reconnected slave. But it’s certainly something being pursued.
  • 1/c – One of the major goals for the near future is to decouple the status from the Buildbot core. The recent introduction of the status DB (replacing on-disk pickle objects for storing status data) is a major step on the path towards this goal, and the migration towards putting more and more of the status data into the db is continuing.
  • 1/d – Another major goal is to move most of the actual logic behind BuildSteps into the master, so that slaves can be thinner. While it might not mean the ability to do without Twisted on build slaves immediately, it’d be one step closer to being able to write alternate buildslaves that wouldn’t require Twisted.
  • 2/b – Buildbot only even committed to supporting multiple repositories in the past 6 months or so, but improving that support now is another goal for the near future.

Miscellaneous

  • 1/e – We get it, preed doesn’t like Twisted, but that said, it’s not as silly a decision as he makes it seem. Twisted provides a lot of simplifying tools for two Twisted-based programs talking to one another, so given that the master users Twisted, it makes sense for the slave to use it as well. (And installing Twisted on Linux is “annoying” by what standards? sudo apt-get install foo works just fine on all of the Linux machines I run…)
  • 2/a – Ironically, I only really began to appreciate the design of Buildbot when I needed to use it for more complex tasks. For “trivial” tasks, it seemed like a lot of setup to do a simple task (as compared to say, a form or two in Hudson to do a simple “make”), but once things moved beyond the simple configure-make-install path to more involved build processes, the flexibility provided by Buildbot’s more generic design became quite appreciated. Buildbot is really a framework for a build system rather than a just-add-water solution like Hudson. Yes, it requires a bit more tweaking to make it do what your specific build process needs, but it can be tweaked to support just about any such process.
  • 2/dbuildbot reload simply re-imports the config file, via Python’s reload() function. Due to how Python implements reload(), the effect is not recursive to child imports unless each parent specifically reload()‘s them as part of its own reload. The fact that Buildbot could be “integrated” with a Python code base in the first place is a feature of Buildbot being written in Python, so blaming Buildbot for Python’s shortcomings seems a bit silly.
  • 2/h – This link doesn’t seem to show what preed  implies it does. catlee’s issues with a quirk of Python had very little to do with Buildbot itself, and far more to do with the differences between __hash__ and __cmp__. One could run into that issue in just about any large-scale Python app.

Conclusion

Buildbot certainly has its flaws. As someone who works with it on a daily basis, I’d be lying if I said I thought it didn’t. That said, I’ve worked with other, similar tools before as well… and they have flaws too. In fact, like any piece of software that isn’t developed from the ground up specifically for your project’s needs, there will be some rough edges if you try to do anything beyond the basics.

That said, I don’t think Buildbot is the worst build system out there, or even one of the worst. I do think, however, that people (including preed) are expecting it to be something different than what it is. Buildbot is not a just-add-water CI server. Buildbot isn’t designed to be “just a CI server” – it’s a framework for distributed build management (UPDATE: It seems I’m not the only one who thinks so, either). A lot of the time, “distributed build management” goes hand in hand with CI – but CI isn’t the only thing Buildbot is used for. You can create a CI system with Buildbot, but you can also create many other systems with it as well, ranging from ad-hoc distributed builds to nightly testing to automated documentation updates. Buildbot’s development is done with this versatility in mind.

Advertisements

About this entry