[Python-Dev] Possible language summit topic: buildbots

"Martin v. Löwis" martin at v.loewis.de
Sun Oct 25 20:24:12 CET 2009

> I think that money can help in two ways in this case.
> First, there are now a multitude of cloud hosting providers which will
> operate a slave machine for you.  BuildBot has even begun to support
> this deployment use-case by allowing you to start up and shut down vms
> on demand to save on costs.  Amazon's EC2 service is supported out of
> the box in the latest release.

Here I'm skeptical. I think we can find people donating always-online
machines still; no need to throw donated money to Amazon.

> Second, there are a number of active BuildBot developers.  One of them
> has even recently taken a contract from Mozilla to implement some non-
> trivial BuildBot enhancements.  I think it very likely that he would
> consider taking such a contract from the PSF for whatever enhancements
> would help out the CPython buildbot.

That could indeed be interesting, assuming we had a clear requirement.
But then, most of us can "easily" fix things in buildbot themselves -
this is python-dev, after all.

>> This is something that only the slave admins can answer. I don't think
>> it's difficult - it's just that people are really unlikely to contribute
>> to the same thing over a period of five years at a steady rate. So we
>> need to make sure to find replacements when people drop out.
> This is a good argument for VMs.

Not really - you still would need somebody to manage them.

> It's certainly *possible* to chase an
> ever changing set of platforms, but it strikes me as something of a
> waste of time.

Hmm - can you really get "strange" operating systems "in the cloud"?
Some of the operating systems that we would like to test don't
even support VMs.

> To me, that raises the question of why people aren't more concerned with
> the status of the build system.  Shouldn't developers care if the code
> they're writing works or not?

I think there are two issues here:
1. some developers actually *don't* care to much whether their code
   works in all cases. If it fails on some strange platform they never
   heard of (such as "Solaris", or "Windows"), they are not bothered by
   the failure. Or, if they care, they still don't know what to do about
   the failure.
2. the buildbots sometimes report false positives. Some tests fail in
   a non-repeatable fashion, only on selected systems. So when you
   change something, the tests break, and you cannot really see how
   this could be possibly related to your change. Then you start
   ignoring these reports - both the bogus ones, and the real ones.


More information about the Python-Dev mailing list