[openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

Doug Hellmann doug at doughellmann.com
Mon Nov 23 16:13:34 UTC 2015


Excerpts from Chris Dent's message of 2015-11-19 20:55:15 +0000:
> On Thu, 19 Nov 2015, Julien Danjou wrote:
> 
> > It would be good to support that as being *normal*, not "potentially
> > incorrect and random"!
> 
> Yes.
> 
> The underlying issue in this thread is the dominance of the six month
> cycle and the way this is perceived to be (any may actually be) a
> benefit for distributors, marketers, etc. That dominance drives the
> technological and social context of OpenStack. No surprise that it is
> present in our tooling and our schedules but sometimes I think it
> would be great if we could fight the power, shift the paradigm, break
> the chains.
> 
> But that's crazy talk, isn't it?

The cycle pattern affects this discussion most directly because of the
distributors, but the social aspects of having the community in a rhythm
are valuable to us, and not just consumers of our work. If we're going
to have a thing called the "Mitaka Release of OpenStack" we should do
that on a schedule. As Thierry says elsewhere in this thread, if a
project isn't releasing at the time of the Mitaka release but has
something compatible with the Mitaka release, that's still a good thing.
It's just not part of the Mitaka release.

> However it is pretty clear the dominance is not aligned with at least
> some of the goals of a big tent. One goal, in particular, is making
> OpenStack stuff useful and accessible to people or groups outside of
> OpenStack where release-often is awesome and the needs of the packagers
> aren't really that important.

Hence the cycle-with-intermediary model.

> I reckon (and this may be an emerging consensus somewhere in this
> thread) we need to make it easier (by declaration) in the tooling
> to test against whatever is desired. Can we enumerate the changes
> required to make that go?



More information about the OpenStack-dev mailing list