Open Stack

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 <thierry at openstack.org> 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 <thierry at openstack.org
> <javascript:;>>
> >> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150409/14d45116/attachment.html>