On 16 November 2016 at 10:11, Gary Kotton <[email protected]> wrote:
> Hi, > > I agree with you on a number of points that you have made below. But you > are mixing things up. One you state that we should be moving faster and it > is patches like this that actually hinder us. We are not moving as the core > team is dwindling down and people are leaving the project. We need to add > new members to the core team and remove people who are not taking part. We > are a community and not an autocracy. It is great that you are driving this > but getting people on board would be helpful. I feel that the cores from > the subprojects should chime in and review this – at the end of the day it > affects them too. I have even asked other to base reviews on this code. I > just think that you need to be aware that there are other people working on > the project and that they too should be engaged. > What's this thread for then if not engaging/inviting people to review? Your point seems moot. > Thanks > > Gary > > > > *From: *"Armando M." <[email protected]> > *Reply-To: *OpenStack List <[email protected]> > *Date: *Wednesday, November 16, 2016 at 6:16 PM > *To: *OpenStack List <[email protected]> > *Subject: *Re: [openstack-dev] [neutron] neutron-lib impact > > > > > > > > On 16 November 2016 at 00:55, Gary Kotton <[email protected]> wrote: > > Hi, > > The directory integration will break all of the plugins and neutron > projects. I do not think that this is something that we should do. It > breaks the neutron API contract. > > > > The plugin directory is an implementation internal. Let's be very clear, > in case you have not realized this already: > > > > *Neutron is not supposed to be imported directly by projects and we all > knew it when we started off with the project decomposition.* > > > > neutron-lib is our response to driving adoption of stable interfaces > across the neutron ecosystem of repositories. Forcing ourselves to > introduce artificial deprecation cycles for internal details is not only > slowing us down but it has proven ineffective so far. We should accelerate > with the decoupling of projects so that we can all consider these types of > breakages a thing of the past. > > > > I think that we should only unblock the patch > https://review.openstack.org/#/c/386845. I think that due to the fact > that this patch (very big) will break all plugins, we should only approve > it once every sub project owner has chimed in. > > This will mean that she/he will need to understand that there may be some > tweaks involved in getting unit tests to pass. CI may automagically work. > > > > This is impractical and defeats the point of allowing us to go faster. I > have taken the proactive step of announcing this change publicly and with > ample notice. I have addressed many subprojects myself and have already > seen +2/+1 flocking in. I have moved forward without creating busy work for > myself and the review team. > > > > I feel that as a core reviewer my responsibility is to make sure that we > do not break things. > > > > We are not in a sane situation. It's been two years since we split the > repo up and very little progress has been made to decouple the projects via > stable interfaces. I am trying to identify ways to allow us to accelerate > and you're stifling that effort with your abuse of core rights. I was not > going to let the patch merge without a final announcement at the next team > meeting. > > > > In addition to this we have a responsibility to ensure that things > continue to work. Hopefully we can find a way to do this in a more friendly > manner. > > > > I have taken such a responsibility with [1]. It takes us longer to discuss > (on something that was already widely agreed on) than either fixing the > breakage or provide a 'fake' backward compat layer which we'll lead to the > breakage as soon we take it away [2]. > > > > That said, I am happy to concede if other members of the core team agrees > with you. As PTL, I have identified a gap that needs to be filled and I am > proactively stepping up to address the gap. I can't obviously be right all > the time, but I was under the impression I had the majority of the core > team on my side. > > > > At this point, I'd invite other neutron core members to review and vote on > the patch. > > > > A. > > > > [1] https://review.openstack.org/#/q/topic:plugin-directory > [2] https://bugs.launchpad.net/vmware-nsx/+bug/1640319 > > > > Thanks > > Gary > > > > *From: *"Armando M." <[email protected]> > *Reply-To: *OpenStack List <[email protected]> > *Date: *Wednesday, November 16, 2016 at 6:51 AM > *To: *OpenStack List <[email protected]> > *Subject: *[openstack-dev] [neutron] neutron-lib impact > > > > Hi neutrinos, > > > > As mentioned during the last team meeting [1], there is a change [2] in > the works aimed at adopting the neutron plugins directory as provided in > neutron-lib 1.0.0 [3]. > > > > As shown in [2], the switch to using the directory is relatively > straightforward. I leave the rest of the affected repos as an exercise for > the reader :) > > > > Cheers, > > Armando > > > > [1] http://eavesdrop.openstack.org/meetings/networking/2016/ > networking.2016-11-14-21.00.txt > > [2] https://review.openstack.org/#/q/topic:plugin-directory > > [3] http://docs.openstack.org/releasenotes/neutron-lib/unreleased.html#id3 > > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
