Open Stack

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.    
> 
> 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