[Numpy-discussion] Buildbot for numpy

Barry Wark barrywark at gmail.com
Mon Jul 2 20:26:15 EDT 2007

I have the potential to add OS X Server Intel (64-bit) and OS X Intel
(32-bit) to the list, if I can convince my boss that the security risk
(including DOS from compile times) is minimal. I've compiled both
numpy and scipy many times, so I'm not worried about resources for a
single compile/test, but can any of the regular developers tell me
about how many commits there are per day that will trigger a

About the more general security risk of running a buildbot slave, from
my reading of the buildbot manual (not the source, yet), it looks like
the slave is a Twisted server that runs as a normal user process. Is
there any sort of sandboxing built into the buildbot slave or is that
the responsibility of the OS (an issue I'll have to discuss with our

On a side note, buildbot.scipy.org goes to the DSP lab, Univ. of
Stellenbosch's home page, not the buildbot status page.


On 6/16/07, Stefan van der Walt <stefan at sun.ac.za> wrote:
> Hi all,
> Short version
> =============
> We now have a numpy buildbot running at
> http://buildbot.scipy.org
> Long version
> ============
> Albert Strasheim and I set up a buildbot for numpy this week.  For
> those of you unfamiliar with The Buildbot, it is
> """
> ...a system to automate the compile/test cycle required by most
> software projects to validate code changes. By automatically
> rebuilding and testing the tree each time something has changed, build
> problems are pinpointed quickly, before other developers are
> inconvenienced by the failure. The guilty developer can be identified
> and harassed without human intervention. By running the builds on a
> variety of platforms, developers who do not have the facilities to
> test their changes everywhere before checkin will at least know
> shortly afterwards whether they have broken the build or not. Warning
> counts, lint checks, image size, compile time, and other build
> parameters can be tracked over time, are more visible, and are
> therefore easier to improve.
> The overall goal is to reduce tree breakage and provide a platform to
> run tests or code-quality checks that are too annoying or pedantic for
> any human to waste their time with. Developers get immediate (and
> potentially public) feedback about their changes, encouraging them to
> be more careful about testing before checkin.
> """
> While we are still working on automatic e-mail notifications, the
> system already provides valuable feedback -- take a look at the
> waterfall display:
> http://buildbot.scipy.org
> If your platform is not currently on the list, please consider
> volunteering a machine as a build slave.  This machine will be
> required to run the buildbot client, and to build a new version of
> numpy whenever changes are made to the repository.  (The machine does
> not have to be dedicated to this task, and can be your own
> workstation.)
> We'd like to thank Robert Kern, Jeff Strunk and Gert-Jan van Rooyen
> who helped us to get the ball rolling, as well as Neilen Marais for
> offering his workstation as a build slave.
> Regards
> Stéfan
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion

More information about the NumPy-Discussion mailing list