openstack team mailing list archive

[Brian Schott <bfschott@xxxxxxxxx>]

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@xxxxxxxxx



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

> 2011/2/17 Jay Pipes <jaypipes@xxxxxxxxx>:
>>> 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/

Attachment: PGP.sig
Description: This is a digitally signed message part