Agreed. I don't think bleeding-edge pip should block a merge either. It could cause a lot of false-positives.
I do think up-to-date Natty, Maverick, and Lucid with build-depends from PPA should be tested, probably CentOS and SUSE if that can be automated. You want apt-get dist-upgrade ; run_test.sh -N to work. How about some automation to "Score your Branch"? Do that BEFORE a branch gets proposed for review. Encourage committers to post their branch score in the bug. At least we when see what is broken. Brian Schott bfsch...@gmail.com On Feb 17, 2011, at 4:21 PM, Soren Hansen wrote: > 2011/2/17 Jay Pipes <jaypi...@gmail.com>: >>> 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/
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
