Open Stack

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)