Open Stack

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
bfschott at gmail.com



On Feb 17, 2011, at 4:21 PM, Soren Hansen wrote:

> 2011/2/17 Jay Pipes <jaypipes at 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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110217/48297fa7/attachment.sig>