Open Stack

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