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? 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? -- Russell Bryant __________________________________________________________________________ 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