2011/2/17 Jay Pipes <[email protected]>: >> One thing we saw in the list and experienced first hand is that your Hudson >> server uses a pre-configured environment and ours pulls virtual env every >> time. We had failures on trunk that yours missed because of new pip pulled >> versions. >> >> A fresh run_tests.sh -f needs to work. It is the only guaranteed sanity >> test everybody can replicate. It might pull upstream bugs, but better to be >> ahead of that curve than behind. > Although Soren adequately explained why he thinks that running > run_tests.sh on Hudson should *not* be against a pip/virtualenv setup, > I would like to state that I think it would be a good idea to have > Hudson do *both*. > > In other words, for each pre-merge into trunk, Hudson would run two things: > > * run_tests.sh -N > * run_tests.sh -V -f
I understand the motivation, I'm just not sure I want the latter to actually block a merge. As an example, the recent race condition I spotted and fixed required a patch to land in eventlet. If the latter was allowed to block a merge, we'd have to keep a known race condition in Nova until upstream decides to do a release so that pip could fetch it. That could take a *long* time. In the mean time, I stuck a fixed Eventlet package in our PPA (and in Ubuntu Natty proper) so that we could move on with our lives and get rid of the race condition. There's simply a flexibility in this approach that I don't see how we can obtain with the pip approach. Again, though, I would be *delighted* to have automated testing on a load of different platforms. I just don't believe they should all be allowed to block us from moving forward. -- Soren Hansen Ubuntu Developer http://www.ubuntu.com/ OpenStack Developer http://www.openstack.org/ _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
