good idea for global requirements Let's submit a multi-project bug on launchpad, and be serious for changing these global requirements in following days
On Thu, Jul 11, 2013 at 7:12 PM, Mark McLoughlin <[email protected]> wrote: > On Wed, 2013-07-10 at 17:07 -0500, Dolph Mathews wrote: > > On Wednesday, July 10, 2013, Sean Dague wrote: > > > > > Yesterday in the very exciting run around to figure out why the gate > was > > > broken, we realized something interesting. Because of the way the gate > > > process pip requirements (one project at a time), on a current gate > run we > > > actually install and uninstall python-keystoneclient 4 times in a > normal > > > run, flipping back and forth from HEAD to 0.2.5. > > > > > > http://paste.openstack.org/**show/39880/< > http://paste.openstack.org/show/39880/>- shows what's going on > > > > > > The net of this means that if any of the projects specify a capped > client, > > > it has the potential for preventing that client from being tested in > the > > > gate. This is very possibly part of the reason we ended up with a > broken > > > python-keystoneclient 0.3.0 released. > > > > > > > I think we need to get strict on projects and prevent them from capping > > > their client requirements. That will also put burden on clients that > they > > > don't break backwards compatibility (which I think was a goal > regardless). > > > However there is probably going to be a bit of pain getting from where > we > > > are today, to this world. > > > > > > Thanks for investigating the underlying issue! I think the same > > policy should apply a bit further to any code we develop and consume > > ourselves as a community (oslo.config, etc). I have no doubt that's the > > standard we strive for, but it's all too easy to throw a cap into a > > requirements file and forget about it. > > I don't think we've ever capped oslo.config anywhere. Got a pointer to > what triggered that concern? > > We should/could be capping oslo.config like this: > > oslo.config>=1.1.0,<2.0 > > because the API stability commitment is that we won't break the API > without bumping the release number to 2.0. I don't anticipate doing 2.0 > soon/ever, so I've never pushed ahead with that capping. > > Cheers, > Mark. > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Gareth *Cloud Computing, OpenStack, Fitness, Basketball* *OpenStack contributor* *Company: UnitedStack <http://www.ustack.com>* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.*
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
