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