Open Stack

On Thu, Nov 19, 2015, at 12:55 PM, Chris Dent wrote:
> 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?
> 
> 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.
> 
> 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?
"Test whatever is desired" is far to nebulous. We need an actual set of
concrete needs and requirements and once you have that you can worry
about enumerating changes. I am not sure I have seen anything like this
in the thread so far.

If you have a stable/X.Y branch or stable/foo but are still wanting to
map onto the 6 month release cycle (we know this because you are running
devstack-gate) how do we make that mapping? is it arbitrary? is there
some deterministic method? Things like this affect the changes necessary
to the tools but should be listed upfront.

Once we have enumerated the problem we can enumerate the changes to fix
it.

Clark