Open Stack

On 10 September 2014 22:23, Russell Bryant <rbryant at redhat.com> wrote:
> 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.

Aren't we trying to move away from the 'usual'? Considering things on
a case by case basis still requires review cycles, etc. Keeping the
status quo would mean prolonging the exact pain we're trying to
address.

>
> 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.
>

I was thinking of the bold move of having Kilo (and beyond)
developments solely focused on this transition. Until this is
complete, nothing would be merged that is not directly pertaining this
objective. At the same time, we'd still want pending features/fixes
(and possibly new features) to land somewhere stable-ish. I fear that
doing so in master, while stuff is churned up and moved out into
external repos, will makes this whole task harder than it already is.

Thanks,
Armando

> --
> Russell Bryant
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev