On Mon, Nov 16, 2015 at 4:03 PM, Russell Bryant <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://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
