Open Stack

On Mon, Nov 16, 2015 at 4:03 PM, Russell Bryant <rbryant at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151116/c84897c8/attachment.html>