<div dir="ltr">I am also looking at a python-keystoneclient release still pending as well. This is being added to the ML topic based on the IRC conversation we just had.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 9, 2015 at 8:20 AM, Morgan Fainberg <span dir="ltr"><<a href="mailto:morgan.fainberg@gmail.com" target="_blank">morgan.fainberg@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Keystonemiddleware is pending a minor fix to sync g-r in a sane way to match the rest of kilo (what we have for keystone et al). <div><br></div><div>However we are blocked because there is no stable Juno and icehouse branches. I'd like to release the Python-keystone client with the requirements update for kilo. </div><div><br></div><div>So keystonemiddleware would receive one more release before the cap. <span></span></div><div class="HOEnZb"><div class="h5"><div><br></div><div><br>On Thursday, April 9, 2015, Thierry Carrez <<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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>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>
</blockquote></div>
</div></div></blockquote></div><br></div>