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.
On Thu, Apr 9, 2015 at 8:20 AM, Morgan Fainberg <[email protected]> wrote: > 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). > > 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. > > So keystonemiddleware would receive one more release before the cap. > > > On Thursday, April 9, 2015, Thierry Carrez <[email protected]> wrote: > >> Doug Hellmann wrote: >> > Excerpts from Dean Troyer's message of 2015-04-08 09:42:31 -0500: >> >> On Wed, Apr 8, 2015 at 8:55 AM, Thierry Carrez <[email protected]> >> >> wrote: >> >> >> >>> The question is, how should we proceed there ? This is new procedure, >> so >> >>> I'm a bit unclear on the best way forward and would like to pick our >> >>> collective brain. Should we just push requirements cap for all >> OpenStack >> >>> libs and create stable branches from the last tagged release >> everywhere >> >>> ? What about other libraries ? Should we push a cap there too ? Should >> >>> we just ignore the whole thing for the Kilo release for all non-Oslo >> stuff >> >>> ? >> >> >> >> Provided that represents the code being used for testing at this >> point, and >> >> I believe it does, this seems like a sensible default action. Next >> cycle >> >> we can make a bit more noise about when this default action will occur, >> >> probably pick one of the other existing dates late in the cycle such >> as RC >> >> or string freeze or whatever. (Maybe that already happened and I can't >> >> remember?) >> > >> > I had hoped to have the spec approved in time to cut releases around >> > the time Oslo did (1 week before feature freeze for applications, >> > to allow us to merge the requirements cap before applications >> > generate their RC1). At this point, I agree that we should go with >> > the most recently tagged versions where possible. It sounds like >> > we have a couple of libs that need releases, and we should evaluate >> > those on a case-by-case basis, defaulting to not updating the stable >> > requirements unless absolutely necessary. >> >> OK, here is a plan, let me know if it makes sense. >> >> If necessary: >> Cinder releases python-cinderclient 1.1.2 >> Designate releases python-designateclient 1.1.2 >> Horizon releases django_openstack_auth 1.2.0 >> Ironic releases python-ironicclient 0.5.1 >> >> Then we cap in requirements stable/kilo branch (once it's cut, when all >> RC1s are done): >> >> python-barbicanclient >=3.0.1 <3.1.0 >> python-ceilometerclient >=1.0.13 <1.1.0 >> python-cinderclient >=1.1.0 <1.2.0 >> python-designateclient >=1.0.0 <1.2.0 >> python-heatclient >=0.3.0 <0.5.0 >> python-glanceclient >=0.15.0 <0.18.0 >> python-ironicclient >=0.2.1 <0.6.0 >> python-keystoneclient >=1.1.0 <1.4.0 >> python-neutronclient >=2.3.11 <2.4.0 >> python-novaclient >=2.22.0 <2.24.0 >> python-saharaclient >=0.8.0 <0.9.0 >> python-swiftclient >=2.2.0 <2.5.0 >> python-troveclient >=1.0.7 <1.1.0 >> glance_store >=0.3.0 <0.5.0 >> keystonemiddleware >=1.5.0 <1.6.0 >> pycadf >=0.8.0 <0.9.0 >> django_openstack_auth>=1.1.7,!=1.1.8 <1.3.0 >> >> As discussed we'll add openstackclient while we are at it: >> >> python-openstackclient>=1.0.0,<1.1.0 >> >> That should trickle down to multiple syncs in multiple projects, which >> we'd merge in a RC2. Next time we'll do it all the same time Oslo did >> it, to avoid creating unnecessary respins (live and learn). >> >> Anything I missed ? >> >> Bonus question: will the openstack proposal bot actually propose >> stable/kilo g-r changes to proposed/kilo branches ? >> >> -- >> Thierry Carrez (ttx) >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
