Open Stack

+1 too, I do think the incubator is a good initiative and a compromise, I just hope it will not be a dumping ground for items that some don't feel are sufficient or don't have a high enough priority for some!
/Alan

-----Original Message-----
From: Sumit Naiksatam [mailto:sumitnaiksatam at gmail.com] 
Sent: August-19-14 7:40 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Network/Incubator proposal (was Re: [Octavia] Minutes from 8/13/2014 meeting)

+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

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