<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Thu, Jul 11, 2013 at 6:12 AM, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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></blockquote><div><br></div><div>No no, I didn't mean to call you out... just using oslo.config as a prime example of a non-client project that should (and from my perspective: does) abide by the same policy.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<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.</blockquote><div><br></div><div style>I think that capping on the major version number is acceptable, as long as we require major version bumps to break backwards compatibility... and don't do major version bumps on a regular basis.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Cheers,<br>
Mark.<br>
<div class=""><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><br></div>-Dolph
</div></div>