Open Stack

+1 for "neutron-labs"! ;-)

On Tue, Aug 19, 2014 at 10:35 AM, Stefano Maffulli
<stefano at openstack.org> wrote:
> 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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev