On 4 September 2014 16:59, Shorya Raj <rajsho...@gmail.com> wrote: >> The limiting factor is generally time - various aspects of the current >> system are clumsy, but they work, so unless someone is particularly >> keen and willing to work through all the factors that led to the >> current setup and propose changes (including at least a rough concept >> of how ongoing maintenance will work), the status quo wins by default. > > If you could outline some of these, I would be willing to have a look at > what I could do.
One that seems promising to me would be to experiment with dynamic testing in OpenStack: http://docs.buildbot.net/latest/manual/cfg-buildslaves.html#openstack Creating test VMs on demand avoids a lot of the security issues otherwise incurred by someone setting up a persistent build slave and provides a more consistent test environment. https://wiki.python.org/moin/BuildBot gives details of the test system configuration details. Due to the overlap with the infrastructure team (to make use of the Rackspace VM resources), infrastruct...@python.org may be a better list to ask for more details on what OpenStack resources we have available (this idea really sits somewhere between infrastructure and python-dev, as Antoine does most of the BuildBot master maintenance). If we could get something like that running, then we might be able to trim the preconfigured buildbot fleet back to just the non-x86 machines. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
