Hi Kyle, Thanks for adding patch [3] to clarify the current API status.
Cathy From: Kyle Mestery [mailto:mest...@mestery.com] Sent: Monday, November 16, 2015 2:16 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron][networking-sfc] Deploying current networking-sfc On Mon, Nov 16, 2015 at 4:03 PM, Russell Bryant <rbry...@redhat.com<mailto:rbry...@redhat.com>> wrote: On 11/16/2015 01:42 PM, Sean M. Collins wrote: > On Mon, Nov 16, 2015 at 04:11:42PM EST, Paul Carver wrote: >> This is a challenge. Personally, I haven't been able to get it all working >> yet. But we're in a dilemma because we want to get good reviews of the code >> before merging. Since the full functionality is quite a lot of code we >> wanted to chop it into more easily reviewable chunks. Unfortunately that >> makes it more difficult to pull it all in at once to test the whole thing >> prior to completing the review and merge. > > I would be concerned about that. I am sympathetic to the chicken and egg > problem of a new repo and new code, but I briefly looked at both of > those reviews and they both are quite large. 1K LOC is usually the upper > limit for a sane patch set. It may be worth trying to break into > smaller, more manageable pieces - even if the initial commits just > create some empty classes and stubbed methods, and then later start > introducing the actual method bodies in small pieces with good unit > tests for each one. Small pieces. Tiny steps. Another thing I've been thinking about is the difference between having a repo like networking-sfc where a sub-group is able to try out new things while also managing expectations with consumers of Neutron. How does someone know the difference between something a bit more experimental vs. when an API is established and can be considered stable and maintained with backwards copmatibility like any other OpenStack REST API? In the case of SFC, consumers of the API should know it's tagged as "release:independent" [1], and also it should be clear there is no release made and the code isn't stable in the docs, but that isn't currently the case looking here [2]. Thus, I've submitted [3] to make this a bit more clear, comments welcome. [1] http://governance.openstack.org/reference/projects/neutron.html [2] http://docs.openstack.org/developer/networking-sfc/ [3] https://review.openstack.org/246001 I think networking-sfc should be able to keep merging code, including the proposed API, but I think it should be clearly marked as experimental and subject to change. That's based on my experience so far studying this proposal, SFC more generally, and watching other efforts happening within Neutron that affect this. How can we manage these expectations more clearly? Well, since it hasn't released yet, I agree, lets experiment and let other backends try this out, and at the same time not lock things down. We just need to be clear about the intent here. Thanks, Kyle -- Russell Bryant __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev