On 07/10/2013 06:07 PM, 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 agree. I think that we have the multi-project integrated gate and all - and we test that trunk of all the server projects work with trunk of all the other server projects - keeping the client projects working like that too seems like an excellent idea - and actually the easiest way to ensure that we do not break anything moving forward. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev