Open Stack

But I do think running a job with lowest version may still help a developer realize that a feature in the latest library is not available in an older supported version. The person can then bump up the library's min version in the requirements. Today, it;s not possible to find this out until someone else runs into an issue with the older lib.

Ref:- I have noticed some bugs in the past and I did post about this to openstack-infra. From Jeremy Stanley's comment on that thread, I understand that it may be tough to setup it up this way due to transitive dependencies. 

-Sabari

On Feb 20, 2014, at 3:06 PM, Sean Dague wrote:

> On 02/20/2014 05:50 PM, Christopher Yeoh wrote:
>> On Thu, 20 Feb 2014 14:45:03 -0500
>> Sean Dague <sean at dague.net> wrote:
>>> 
>>> So I'm one of the first people to utter "if it isn't tested, it's
>>> probably broken", however I also think we need to be realistic about
>>> the fact that if you did out the permutations of dependencies and
>>> config options, we'd have as many test matrix scenarios as grains of
>>> sand on the planet.
>> 
>> I think it makes sense to at test with all the most recent versions.
>> Perhaps all the lowest as well, though I'm not sure how common that
>> configuration would really be. And we can't do all of the various
>> combinations. 
>> 
>> But how about testing on a periodic job the version
>> configurations used by some of the major distros? So we know on which
>> distros we're going to be broken on by default (if we don't get around
>> to fixing them straight away) which will really help inform those
>> trying out the latest from git. Or are the distros doing this anyway
>> (either way having the info public and feeding back to our bug tracker
>> would be handy).
> 
> Honestly, I think our experience in even doing a homogenous gate means I
> think we should let the distros come in with 3rd party testing on those
> results. Because we don't really have the bw, in either people or
> machines, to explode that matrix much in infra.
> 
> 	-Sean
> 
> -- 
> Sean Dague
> Samsung Research America
> sean at dague.net / sean.dague at samsung.com
> https://urldefense.proofpoint.com/v1/url?u=http://dague.net/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=t%2BccgWNa3RGhEJzfoLbZKcoWP6fDp0ZLoIyTd0CiIdk%3D%0A&m=kRy3u472erydn9aD1jOg%2FCQqzv1p0pQeNd%2BI8WXeZLk%3D%0A&s=493bac7a717a985bdb4d64eca320969ecb2a6df00d7ee8f5d8bcaf895dd24fe8
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=t%2BccgWNa3RGhEJzfoLbZKcoWP6fDp0ZLoIyTd0CiIdk%3D%0A&m=kRy3u472erydn9aD1jOg%2FCQqzv1p0pQeNd%2BI8WXeZLk%3D%0A&s=d484eedf637b01155f20eeda79378a9d506d6a39060517e70e868dcab571f3c6

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140220/06980919/attachment.html>