On 09/10/2015 03:45 PM, Robert Collins wrote: > On 11 September 2015 at 07:23, Robert Collins <robe...@robertcollins.net> > wrote: >> Note that master is pinned: >> >> commit aca1a74909d7a2841cd9805b7f57c867a1f74b73 >> Author: Tushar Gohad <tushar.go...@intel.com> >> Date: Tue Aug 18 07:55:18 2015 +0000 >> >> Restrict PyECLib version to 1.0.7 >> >> v1.0.9 rev of PyECLib replaces Jerasure with a native EC >> implementation (liberasurecode_rs_vand) as the default >> EC scheme. Going forward, Jerasure will not be bundled >> with PyPI version of PyECLib as it used to be, until >> v1.0.7. >> >> This is an interim change to Global/Swift requirements >> until we get v1.0.9 PyECLib released and included in >> global-requirements and ready patches that change Swift >> default ec_type (for doc, config samples and unit tests) >> from "jerasure_rs_vand" to "liberasurecode_rs_vand." >> >> Without this change, Swift unit tests will break at gate >> as soon as PyECLib v1.0.9 lands on PyPI >> >> * Swift is the only user of PyECLib at the moment >> >> Change-Id: I52180355b95679cbcddd497bbdd9be8e7167a3c7 >> >> >> But it appears a matching change was not done to j/k - and the pin >> hasn't been removed from master. > > I'm going to propose another manual review rule I think: we should not > permit lower releases to use higher versions of libraries - > approximately noone tests downgrades of their thing [and while it only > matters for packages with weird installs / state management things, > its a glaring hole in our reliability story].
I feel like that's a bad thing to assume of people's systems. What is the expected behavior of an installer if it discovers installing OpenStack requires downgrading a library? Halt and catch fire? It also means we're back to having to pin requirements in stable branches because that's the only way we can guaruntee this for people. And that's a thing we specifically wanted to get out of the business of doing because it let to all kinds of problems. -Sean -- Sean Dague http://dague.net __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev