Open Stack

On 08/19/2014 08:39 AM, Eichberger, German wrote:
> Just to be clear: We all think the incubator is a great idea and if
> some things are ironed out will be a good way to onboard new projects
> to Neutron. What bothers me is the timing. Without warning we were
> put in an incubator in the span of like 8 days. 

No, not without warning: 8 days and we're still discussing the solution
for code that has been developed by sub-teams and for which the core
team has not reached consensus whether to merge it or not. As a
reminder, until we started this discussion, the alternative for 'lack of
consensus 3 days before feature freeze' was to leave code out of the
tree. We've done it that way in the past.

Incubator is a *proposal* to improve the situation, provide a way for
code that is considered mature by a sub-team to be shipped to customers
from a git.openstack.org repository (as opposed from somewhere else, as
it happened in the past).

The full details are on this wiki page:
https://wiki.openstack.org/wiki/Network/Incubator

> This makes it
> difficult to plan and adds unnecessary uncertainty. Who is
> guaranteeing that if I tell my management LBaaS v2 will be in Kilo
> that nobody will throw a wrench in five months time?

Great question! There is no simple answer: it's a risk everyone involved
in OpenStack decides to run because that risk of a last minute wrench is
balanced by the benefits of getting back a full working engine and spare
parts, with manuals.

That said, there are a lot of ways to mitigate that risk in any case.
One is to pay attention to the priorities set by the project leaders and
help them, first.

Us, the people on this list, should be the ones explaining our managers
what this OpenStack collaboration is all about. If it's not clear to you
how, come to the Upstream Training sessions in Paris to get some ideas.
https://wiki.openstack.org/wiki/OpenStack_Upstream_Training

> What I like to see from the Neutron Core team is timely communication
> with proper transition plans: For example if there is a change in how
> things are done it should be implemented at the beginning of a cycle
> and projects started before the change should have a grace period
> where things are done the old way. I understand that some things
> might have to be retroactively but that should be kept to a minimum -

Yep, this is a very reasonable request. I think the that Neutron Core
Team (and other teams, too) has space for improvements in the way they
communicate to sub-teams and to the Foundation.

This change comes too close to the end of the cycle, I agree and I think
I understand the pain you're going through: it's bad. The only reason
why I support this effort to change *now* is that the alternative to a
new repository with LBaaSv2 code is more likely to be a 'no, come back
for Kilo' (based on past experience). I find the 'no' to be unacceptable
and 'yes' very unlikely. Incubator sounds like a good compromise.

I'd focus our energies to addressing the shortcomings of the Incubator
proposal. I, to start, would advocate for calling this repository
'Labs', a place where cool and interesting things are given a chance to
be tried out and if they stick, users like them, moved to a more
permanent home (or die). Incubator sound too much like something that
needs maturing and it may not be the case (plus it sounds too
burocratic, with rules to graduation, etc).

The sooner we iron out the wrinkles in the proposal the sooner we start
educating distributions that there is good code in there that they may
want to package and ship to users.


/stef

-- 
Ask and answer questions on https://ask.openstack.org