Open Stack

Excerpts from Sean Dague's message of 2015-04-08 10:49:15 -0400:
> On 04/08/2015 10:42 AM, Dean Troyer wrote:
> > On Wed, Apr 8, 2015 at 8:55 AM, Thierry Carrez <thierry at openstack.org
> > <mailto: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?)
> 
> Yes, due to the way we're testing client libraries, that's the right
> approach. In future we should fully cap GR as the first Milestone 3
> task. And everything after that should be managed as an exception to get
> bumps.

This cycle we actually froze Oslo libs a week before K3, which gave
us time to create the stable branches and update the requirements
caps for K3. I recommend other library managers consider using the
same rough schedule for their freeze. I'll also note that freezing
early works much much better if you are releasing updates to the
library frequently, so we shouldn't be shy about releasing new
client libraries more than once or twice per cycle.

Given the cascading test jobs triggered by landing requirements
changes, we should try to consolidate the updates to the global
list for all of the caps (one patch would be ideal, but may not be
realistic).

Doug

> 
> >     All other non-Oslo libs in the OpenStack world do not seem to be
> >     directly consumed by projects that have stable branches, and are
> >     therefore likely to not maintain stable branches. Please report any
> >     glaring omission there.
> > 
> > 
> > OSC is not used by any of the integrated release projects but due to its
> > dependencies on the other client libs and use in DevStack I would like
> > to follow the same process for it here.  The current 1.0.3 release is
> > the one that should be used for stable.
> 
> Agreed.
> 
>     -Sean
>