Open Stack

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 <morgan.fainberg at gmail.com>
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 <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>
>> >> 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/f238eea0/attachment.html>