Open Stack

On Fri, Sep 20, 2013 at 11:52 AM, Russell Bryant <rbryant at redhat.com> wrote:

> On 09/20/2013 02:02 PM, Dan Wendlandt wrote:
> > I think the real problem here is that in Nova there are bug fixes that
> > are tiny and very important to a particular subset of the user
> > population and yet have been around for well over a month without
> > getting a single core review.
> >
> > Take for example https://review.openstack.org/#/c/40298/ , which fixes
> > an important snapshot bug for the vmwareapi driver.  This was posted
> > well over a month ago on August 5th.  It is a solid patch, is 54
> > new/changed lines including unit test enhancements.  The commit message
> > clearly shows which tempest tests it fixes.  It has been reviewed by
> > many vmware reviewers with +1s for a long time, but the patch just keeps
> > having to be rebased as it sits waiting for core reviewer attention.
>

Personally I tend not to review many vmwareapi patches because without
seeing any public functional tests or being able to run the patch myself, I
am uncomfortable saying it 'looks good to me'. All I can do is make sure
the code looks pythonic and make no assessment on if the patch works or
not. With no shortage of patches to review I tend to review other patches
instead.

I while back Russell announced we would like all virt drivers have a public
functional testing system by the release of Icehouse (
http://lists.openstack.org/pipermail/openstack-dev/2013-July/011280.html).
Public functional testing would allow me to review vmwareapi patches with
almost the same level of confidence as with a driver that we gate on and
that I can trivially try out, such as libvirt.  Until then, if we put an
explicit comment in the release notes explicitly saying that vmwareapi is a
group C virt driver (https://wiki.openstack.org/wiki/HypervisorSupportMatrix --
"These drivers have minimal testing and may or may not work at any given
time. Use them at your own risk") that would address my concerns and I
would be happy to +2 vmwareapi patches based just on if the code looks
correct and not on how well the patch works.


>
> > To me, the high-level take away is that it is hard to get new
> > contributors excited about working on Nova when their well-written and
> > well-targeted bug fixes just sit there, getting no feedback and not
> > moving closer to merging.  The bug above was the developer's first patch
> > to OpenStack and while he hasn't complained a bit, I think the
> > experience is far from the community behavior that we need to encourages
> > new, high-quality contributors from diverse sources.  For Nova to
> > succeed in its goals of being a platform agnostic cloud layer, I think
> > this is something we need a community strategy to address and I'd love
> > to see it as part of the discussion put forward by those people
> > nominating themselves as PTL.
>
> I've discussed this topic quite a bit in the past.  In short, my
> approach has been:
>
> 1) develop metrics
> 2) set goals
> 3) track progress against those goals
>
> The numbers I've been using are here:
>
>     http://russellbryant.net/openstack-stats/nova-openreviews.html
>
> Right now we're running a bit behind the set goal of keeping the average
> under 5 days for the latest revision (1st set of numbers), and 7 days
> for the oldest revision since the last -1 (3rd set of numbers).
> However, Nova is now (and has been since I've been tracking this) below
> the average for all OpenStack projects:
>
>     http://russellbryant.net/openstack-stats/all-openreviews.html
>
> Review prioritization is not something that I or anyone else can
> strictly control, but we can provide tools and guidelines to help.  You
> can find some notes on that here:
>
>     https://wiki.openstack.org/wiki/Nova/CoreTeam#Review_Prioritization
>
> There is also an aspect of karma involved in all of this that I think
> phttp://summit.openstack.org/cfp/details/4lays a big part when it comes
> to the vmware driver patches.  To get review attention, someone has to
> *want* to review it.  To get people to want to review your stuff, it can
> either be technology they are interested in, or they just want to help
> you out personally.
>
> There aren't many Nova developers that use the vmware driver, so you've
> got to work on building karma with the team.  That means contributing to
> other areas, which honestly, I haven't seen much of from this group.  I
> think that would go a long way.
>
> I think if you review the history of vmware patches, you'll see my name
> as a reviewer on many (or perhaps most) of them, so I hope nobody thinks
> that I personally am trying stall things here.  This is just based on my
> experience across all contributions.
>
> I already put a session on the design summit schedule to discuss the
> future of drivers.  I'm open to alternative approaches for driver
> maintenance, including moving some of them (such as the vmware driver)
> into another tree where the developers focused on it can merge their
> code without waiting for nova-core review.
>
> http://summit.openstack.org/cfp/details/4
>
> --
> Russell Bryant
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20130920/8c6a348b/attachment.html>