<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 16, 2015 at 4:03 PM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 11/16/2015 01:42 PM, Sean M. Collins wrote:<br>
> On Mon, Nov 16, 2015 at 04:11:42PM EST, Paul Carver wrote:<br>
>> This is a challenge. Personally, I haven't been able to get it all working<br>
>> yet. But we're in a dilemma because we want to get good reviews of the code<br>
>> before merging. Since the full functionality is quite a lot of code we<br>
>> wanted to chop it into more easily reviewable chunks. Unfortunately that<br>
>> makes it more difficult to pull it all in at once to test the whole thing<br>
>> prior to completing the review and merge.<br>
><br>
> I would be concerned about that. I am sympathetic to the chicken and egg<br>
> problem of a new repo and new code, but I briefly looked at both of<br>
> those reviews and they both are quite large. 1K LOC is usually the upper<br>
> limit for a sane patch set. It may be worth trying to break into<br>
> smaller, more manageable pieces - even if the initial commits just<br>
> create some empty classes and stubbed methods, and then later start<br>
> introducing the actual method bodies in small pieces with good unit<br>
> tests for each one. Small pieces. Tiny steps.<br>
<br>
Another thing I've been thinking about is the difference between having<br>
a repo like networking-sfc where a sub-group is able to try out new<br>
things while also managing expectations with consumers of Neutron.  How<br>
does someone know the difference between something a bit more<br>
experimental vs. when an API is established and can be considered stable<br>
and maintained with backwards copmatibility like any other OpenStack<br>
REST API?<br>
<br></blockquote><div>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.<br><br>[1] <a href="http://governance.openstack.org/reference/projects/neutron.html">http://governance.openstack.org/reference/projects/neutron.html</a><br>[2] <a href="http://docs.openstack.org/developer/networking-sfc/">http://docs.openstack.org/developer/networking-sfc/</a><br></div><div>[3] <a href="https://review.openstack.org/246001">https://review.openstack.org/246001</a><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I think networking-sfc should be able to keep merging code, including<br>
the proposed API, but I think it should be clearly marked as<br>
experimental and subject to change.  That's based on my experience so<br>
far studying this proposal, SFC more generally, and watching other<br>
efforts happening within Neutron that affect this.<br>
<br>
How can we manage these expectations more clearly?<br>
<span class=""><font color="#888888"><br></font></span></blockquote><div>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.<br><br></div><div>Thanks,<br></div><div>Kyle<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""><font color="#888888">
--<br>
Russell Bryant<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><br></div></div>