Open Stack

Hi Alan,

Just wondering why the +1 for this.
It would seem that a better way of doing this without what seems like a
guaranteed method of disruption would be to run a neutron forge activity
and integrate the work once it is proved stable and the impacts on
existing functions can be well understood.

Is there a good reason that the PDU thinks will help them to run it in
this way?

/ Chris

On 8/19/14, 11:05 PM, "Alan Kavanagh" <alan.kavanagh at ericsson.com> wrote:

>+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
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev