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

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to