Open Stack

Hi Russell,

Thanks for the detailed thoughts.  Comments below,

Dan


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


Its great that you have dashboards like this, very cool.  The interesting
thing here is that the patches I am talking about are not waiting on
reviews in general, but rather core review.  They have plenty of reviews
from non-core folks who provide feedback (and they keep getting +1'd again
as they are rebased every few days).  Perhaps a good additional metric to
track would be be items that have spent a lot of time without a negative
review, but have not gotten any core reviews.  I think that is the root of
the issue in the case of the reviews I'm talking about.



>
> 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 agree with you on the dynamics of review karma here (having dealt with
this same issue as a PTL of Quantum/Neutron).  My sense of of is going on
here is a bootstrapping issue.  If you have a developer who is brand new to
OpenStack, it would make sense that your first patch or two would be in an
area where you feel most comfortable (e.g., because you understand the
VMware APIs + constructs).  For new developers, who aren't pushing a big
new feature but are instead just fixing an existing bug, I would not
guessed that a huge amount of karma is needed for a review.  People like
garyk and arosen who have more Nova experience are already doing Nova work
outside of the VMware driver (instance groups, neutron / security groups
code, many reviews throughout Nova, not to mention their work in Neutron)
and I expect that to be the path others follow as well.  Nonetheless, I
like the suggestion of having these new developers also try to gain
experience outside of the vmware driver and provide value to the wider
community... is
https://bugs.launchpad.net/nova/+bugs?field.tag=low-hanging-fruit still the
best place for them to look?  Doesn't seem to be much there that isn't
already in progress.



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

Indeed, and in fact, when I first wrote the email, I had called out you,
Dan Smith, and Michael Still as having been very helpful with VMware API
review, but then I was worried that I had left people off the list that had
also been helpful but weren't immediately coming to mind.  I guess I was
damned if I did and damned if I didn't :)

My goal in sending the email was not to personally praise or condemn any
individuals, but rather to point out that there is a group of people who
are finding it difficult to effectively join the Nova community.  I
obviously have more exposure to the VMware driver side of things, but I
wouldn't be surprised if others have the same challenges.


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


Discussing better strategies for the helping the review process was my
original goal in sending the initial email.  At least at first glance,
moving some drivers to another tree doesn't strike me as the right
approach.  As you pointed out above, the end goal is to grow these new
contributors to be people who can contribute more broadly across the Nova
codebase, so moving them to another tree where they don't naturally
interact with the rest of the Nova community seems counter-intuitive to me.
 Many of these folks want to contribute and become full Nova members and
even core contributors, its just very hard for them to get started despite
the fact that they are fixing real bugs in existing Nova code.  But maybe
there's an angle I'm missing, so I'm happy to discuss this at the summit.

I actually think that if we could get core reviewers regularly looking at a
dashboard that highlights bug fixes that have gone a long time since the
last core reviewer feedback, that would go a long way already.  If we could
find a way a good way to make reviews from new contributors, who
legitimately have not been able to yet build up karma yet, stand out, that
would be even better in terms of helping grow the set of people who can
contribute to Nova.




>
>
> --
> Russell Bryant
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130920/ff71d3ae/attachment.html>