Robert Bradshaw, 17.11.2010 09:59: > 1. The web site > 5. Buildbot > > In terms of the website itself, I think we should keep hosting that > (for maximum flexibility, and it's easy to administer)
+1 > and there > isn't much of an option for 5 (though steps should be taken to reduce > its load). I'm a big fan of timely commit feedback. Hudson is already down to 6 build threads, so it takes a while now to finish the test suites. Also, the less parallel builds we run, the longer it disturbs other programs on the same machine. Could you describe a little where you think the current pain points are? Is it more about the number of builds per day or the overall load during a single build? I/O or CPU load? My impression is that the /scratch/hudson mount point doesn't have very fast I/O, which lets the builds take longer than necessary. A problem that I see is that Hudson only checks for changes every 10 minutes in order to keep the load of the (fairly slow) Cython VM acceptable. So if a new commit arrives shortly after triggering the builds, it will continue to run the tests for 10 minutes before it starts over and does it all again. I tried changing that with the commit hook script but didn't get a response. I don't know if bitbucket supports commit hooks, BTW. One way to get relief is to reduce the currently 9 jobs that all query the cython-devel repo for changes. I can try to change that by adding a dedicated source build job that does the polling and triggers the real build jobs that just download the sdist with no hg interaction. That moves the hg change history one step further away from the build result on the Hudson job page, but that won't hurt anyone, I guess. Stefan _______________________________________________ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev
