Open Stack

On 02/23/2015 04:02 PM, Sean Dague wrote:
> On 02/23/2015 03:45 PM, Dan Smith wrote:
>>> Seriously, what is the point of 6-month releases again? We are a
>>> free-form open source set of projects, with a lot of intelligent
>>> engineers. Why are we stuck using an outdated release model?
>>
>> I've been wondering this myself for quite a while now. I'm really
>> interested to hear what things would look like in a no-release model.
>> I'm sure it would be initially met with a lot of resistance, but I think
>> that in the end, it makes more sense to move to that sort of model and
>> let vendors/deployers more flexibly decide when to roll out new stuff
>> based on what has changed and what they value.
>
> What's the alternative proposed release model?

Release at-will. No pre-determined date-based releases. Smaller list of 
features in each tagged release. Focus on API versioning, not releases.

> What's the compatibility story with Glance / Neutron / Cinder in
> whatever that model is?

Exactly the same as it is now: everything is based on the server 
supported API version and the python-xxxclient release that understands 
that server API version, and integrating support for that client release 
into Nova. There's really very little different at this point between 
our usage of python-neutronclient and our usage of the requests Python 
library. We should pin to a particular library version that we make use 
of the features from, and upgrade the pinning when we utilize 
functionality that is a newer release.

> What's the sliding upgrade window look like?

Whatever we want to make it. :) With our RPC and object versioning 
functionality, we can drop support for some old RPC API and object 
versions after some arbitrary amount of time (check with operators and 
get sign off, then just do it).

> What's the stable maint story look like? the security fix story?

"stable maintenance" should be entirely left up to the distributions, IMO.

Security fix story should be up to the distributions to track when their 
products are patched. Upstream should be concerned with quick fixes into 
the upstream branches and coordinated communication with distributions.

> I get being frustrated with a thing, but there are a lot of
> considerations before redoing the release cycle.

Understood completely. But I'm curious to see just how much grief we put 
ourselves through in trying to do date-based releases when our 
contributor community just isn't assembled in a way that makes those 
releases seem reasonable.

Best,
-jay