Open Stack

On 09/10/2014 10:35 PM, Armando M. wrote:
> Hi,
> 
> I devoured this thread, so much it was interesting and full of
> insights. It's not news that we've been pondering about this in the
> Neutron project for the past and existing cycle or so.
> 
> Likely, this effort is going to take more than two cycles, and would
> require a very focused team of people working closely together to
> address this (most likely the core team members plus a few other folks
> interested).
> 
> One question I was unable to get a clear answer was: what happens to
> existing/new bug fixes and features? Would the codebase go in lockdown
> mode, i.e. not accepting anything else that isn't specifically
> targeting this objective? Just using NFV as an example, I can't
> imagine having changes supporting NFV still being reviewed and merged
> while this process takes place...it would be like shooting at a moving
> target! If we did go into lockdown mode, what happens to all the
> corporate-backed agendas that aim at delivering new value to
> OpenStack?

Yes, I imagine a temporary slow-down on new feature development makes
sense.  However, I don't think it has to be across the board.  Things
should be considered case by case, like usual.

For example, a feature that requires invasive changes to the virt driver
interface might have a harder time during this transition, but a more
straight forward feature isolated to the internals of a driver might be
fine to let through.  Like anything else, we have to weight cost/benefit.

> Should we relax what goes into the stable branches, i.e. considering
> having  a Juno on steroids six months from now that includes some of
> the features/fixes that didn't land in time before this process kicks
> off?

No ... maybe I misunderstand the suggestion, but I definitely would not
be in favor of a Juno branch with features that haven't landed in master.

-- 
Russell Bryant