<div dir="ltr">good idea for <span style="font-family:arial,sans-serif;font-size:13px">global requirements</span><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><font face="arial, sans-serif">Let's submit a multi-project bug on launchpad, and be serious for changing these global requirements in following days</font></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 11, 2013 at 7:12 PM, Mark McLoughlin <span dir="ltr"><<a href="mailto:markmc@redhat.com" target="_blank">markmc@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wed, 2013-07-10 at 17:07 -0500, Dolph Mathews wrote:<br>
> On Wednesday, July 10, 2013, Sean Dague wrote:<br>
><br>
> > Yesterday in the very exciting run around to figure out why the gate was<br>
> > broken, we realized something interesting. Because of the way the gate<br>
> > process pip requirements (one project at a time), on a current gate run we<br>
> > actually install and uninstall python-keystoneclient 4 times in a normal<br>
> > run, flipping back and forth from HEAD to 0.2.5.<br>
> ><br>
</div>> > <a href="http://paste.openstack.org/**show/39880/" target="_blank">http://paste.openstack.org/**show/39880/</a><<a href="http://paste.openstack.org/show/39880/" target="_blank">http://paste.openstack.org/show/39880/</a>>- shows what's going on<br>

<div class="im">> ><br>
> > The net of this means that if any of the projects specify a capped client,<br>
> > it has the potential for preventing that client from being tested in the<br>
> > gate. This is very possibly part of the reason we ended up with a broken<br>
> > python-keystoneclient 0.3.0 released.<br>
><br>
><br>
> > I think we need to get strict on projects and prevent them from capping<br>
> > their client requirements. That will also put burden on clients that they<br>
> > don't break backwards compatibility (which I think was a goal regardless).<br>
> > However there is probably going to be a bit of pain getting from where we<br>
> > are today, to this world.<br>
><br>
><br>
> Thanks for investigating the underlying issue! I think the same<br>
> policy should apply a bit further to any code we develop and consume<br>
> ourselves as a community (oslo.config, etc). I have no doubt that's the<br>
> standard we strive for, but it's all too easy to throw a cap into a<br>
> requirements file and forget about it.<br>
<br>
</div>I don't think we've ever capped oslo.config anywhere. Got a pointer to<br>
what triggered that concern?<br>
<br>
We should/could be capping oslo.config like this:<br>
<br>
  oslo.config>=1.1.0,<2.0<br>
<br>
because the API stability commitment is that we won't break the API<br>
without bumping the release number to 2.0. I don't anticipate doing 2.0<br>
soon/ever, so I've never pushed ahead with that capping.<br>
<br>
Cheers,<br>
Mark.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><font color="#444444">Gareth</font><div><font color="#444444"><br></font><div><i><font color="#444444">Cloud Computing, OpenStack, Fitness, Basketball</font></i></div>
<div><i><font color="#666666">OpenStack contributor</font></i></div><div><i><font color="#666666">Company: <a href="http://www.ustack.com" target="_blank">UnitedStack</a></font></i></div><div><i><font color="#999999">My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me </font></i></div>
<div><i><font color="#999999">and I'll donate $1 or ¥1 to an open organization you specify.</font></i></div></div></div>
</div>