<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Apr 9, 2015 at 11:23 AM, Akihiro Motoki <span dir="ltr"><<a href="mailto:amotoki@gmail.com" target="_blank">amotoki@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Neutron team has a plan to release a new version of neutornclient for Kilo.<br>
We waited the new release until all granted FFE patches land,<br>
and now we are almost ready to go. (waiting one patch in the gate)<br>
<br>
The planned new version is 2.4.0. It is because neutronclient uses 2.3.x version<br>
for a long time (including Kilo) and we would like to have a room for<br>
bug fixing for Juno release.<br>
So we would like to propose the following for Kilo:<br>
<br>
  python-neutronclient >=2.4.0 <2.5.0<br>
<br>
I am in the same page with Kyle.<br>
I hope this plan is acceptable.<br>
<br></blockquote><div>Can we request a requirements FFE for the following patch [1]? This will set Liberty up to use the 2.5.x series for python-neutronclient, per what Akihiro and I have planned. The Juno patch should hopefully merge soon [2], which caps Juno to something appropriate as well.<br><br></div><div>Thanks<br></div><div>Kyle<br></div><div><br>[1] <a href="https://review.openstack.org/#/c/172149/">https://review.openstack.org/#/c/172149/</a><br></div><div>[2] <a href="https://review.openstack.org/#/c/172150/">https://review.openstack.org/#/c/172150/</a><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Thanks,<br>
Akihiro<br>
<div class=""><div class="h5"><br>
<br>
2015-04-10 0:09 GMT+09:00 Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>>:<br>
> Doug Hellmann wrote:<br>
>> Excerpts from Dean Troyer's message of 2015-04-08 09:42:31 -0500:<br>
>>> On Wed, Apr 8, 2015 at 8:55 AM, Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>><br>
>>> wrote:<br>
>>><br>
>>>> The question is, how should we proceed there ? This is new procedure, so<br>
>>>> I'm a bit unclear on the best way forward and would like to pick our<br>
>>>> collective brain. Should we just push requirements cap for all OpenStack<br>
>>>> libs and create stable branches from the last tagged release everywhere<br>
>>>> ? What about other libraries ? Should we push a cap there too ? Should<br>
>>>> we just ignore the whole thing for the Kilo release for all non-Oslo stuff<br>
>>>> ?<br>
>>><br>
>>> Provided that represents the code being used for testing at this point, and<br>
>>> I believe it does, this seems like a sensible default action.  Next cycle<br>
>>> we can make a bit more noise about when this default action will occur,<br>
>>> probably pick one of the other existing dates late in the cycle such as RC<br>
>>> or string freeze or whatever. (Maybe that already happened and I can't<br>
>>> remember?)<br>
>><br>
>> I had hoped to have the spec approved in time to cut releases around<br>
>> the time Oslo did (1 week before feature freeze for applications,<br>
>> to allow us to merge the requirements cap before applications<br>
>> generate their RC1). At this point, I agree that we should go with<br>
>> the most recently tagged versions where possible. It sounds like<br>
>> we have a couple of libs that need releases, and we should evaluate<br>
>> those on a case-by-case basis, defaulting to not updating the stable<br>
>> requirements unless absolutely necessary.<br>
><br>
> OK, here is a plan, let me know if it makes sense.<br>
><br>
> If necessary:<br>
> Cinder releases python-cinderclient 1.1.2<br>
> Designate releases python-designateclient 1.1.2<br>
> Horizon releases django_openstack_auth 1.2.0<br>
> Ironic releases python-ironicclient 0.5.1<br>
><br>
> Then we cap in requirements stable/kilo branch (once it's cut, when all<br>
> RC1s are done):<br>
><br>
> python-barbicanclient >=3.0.1 <3.1.0<br>
> python-ceilometerclient >=1.0.13 <1.1.0<br>
> python-cinderclient >=1.1.0 <1.2.0<br>
> python-designateclient >=1.0.0 <1.2.0<br>
> python-heatclient >=0.3.0 <0.5.0<br>
> python-glanceclient >=0.15.0 <0.18.0<br>
> python-ironicclient >=0.2.1 <0.6.0<br>
> python-keystoneclient >=1.1.0 <1.4.0<br>
> python-neutronclient >=2.3.11 <2.4.0<br>
> python-novaclient >=2.22.0 <2.24.0<br>
> python-saharaclient >=0.8.0 <0.9.0<br>
> python-swiftclient >=2.2.0 <2.5.0<br>
> python-troveclient >=1.0.7 <1.1.0<br>
> glance_store >=0.3.0 <0.5.0<br>
> keystonemiddleware >=1.5.0 <1.6.0<br>
> pycadf >=0.8.0 <0.9.0<br>
> django_openstack_auth>=1.1.7,!=1.1.8 <1.3.0<br>
><br>
> As discussed we'll add openstackclient while we are at it:<br>
><br>
> python-openstackclient>=1.0.0,<1.1.0<br>
><br>
> That should trickle down to multiple syncs in multiple projects, which<br>
> we'd merge in a RC2. Next time we'll do it all the same time Oslo did<br>
> it, to avoid creating unnecessary respins (live and learn).<br>
><br>
> Anything I missed ?<br>
><br>
> Bonus question: will the openstack proposal bot actually propose<br>
> stable/kilo g-r changes to proposed/kilo branches ?<br>
><br>
> --<br>
> Thierry Carrez (ttx)<br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
<br>
<br>
<br>
</div></div><span class=""><font color="#888888">--<br>
Akihiro Motoki <<a href="mailto:amotoki@gmail.com">amotoki@gmail.com</a>><br>
</font></span><div class=""><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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></div></div>