<div dir="ltr">Hi Russell, <div><br></div><div>Thanks for the detailed thoughts. Comments below,</div><div><br></div><div>Dan<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Sep 20, 2013 at 11:52 AM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>On 09/20/2013 02:02 PM, Dan Wendlandt wrote:<br>
> I think the real problem here is that in Nova there are bug fixes that<br>
> are tiny and very important to a particular subset of the user<br>
> population and yet have been around for well over a month without<br>
> getting a single core review.<br>
><br>
> Take for example <a href="https://review.openstack.org/#/c/40298/" target="_blank">https://review.openstack.org/#/c/40298/</a> , which fixes<br>
> an important snapshot bug for the vmwareapi driver. This was posted<br>
> well over a month ago on August 5th. It is a solid patch, is 54<br>
> new/changed lines including unit test enhancements. The commit message<br>
> clearly shows which tempest tests it fixes. It has been reviewed by<br>
> many vmware reviewers with +1s for a long time, but the patch just keeps<br>
> having to be rebased as it sits waiting for core reviewer attention.<br>
><br>
> To me, the high-level take away is that it is hard to get new<br>
> contributors excited about working on Nova when their well-written and<br>
> well-targeted bug fixes just sit there, getting no feedback and not<br>
> moving closer to merging. The bug above was the developer's first patch<br>
> to OpenStack and while he hasn't complained a bit, I think the<br>
> experience is far from the community behavior that we need to encourages<br>
> new, high-quality contributors from diverse sources. For Nova to<br>
> succeed in its goals of being a platform agnostic cloud layer, I think<br>
> this is something we need a community strategy to address and I'd love<br>
> to see it as part of the discussion put forward by those people<br>
> nominating themselves as PTL.<br>
<br>
</div>I've discussed this topic quite a bit in the past. In short, my<br>
approach has been:<br>
<br>
1) develop metrics<br>
2) set goals<br>
3) track progress against those goals<br>
<br>
The numbers I've been using are here:<br>
<br>
<a href="http://russellbryant.net/openstack-stats/nova-openreviews.html" target="_blank">http://russellbryant.net/openstack-stats/nova-openreviews.html</a></blockquote><div><br></div><div style>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. </div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
There is also an aspect of karma involved in all of this that I think<br>
phttp://<a href="http://summit.openstack.org/cfp/details/4lays" target="_blank">summit.openstack.org/cfp/details/4lays</a> a big part when it comes<br>
to the vmware driver patches. To get review attention, someone has to<br>
*want* to review it. To get people to want to review your stuff, it can<br>
either be technology they are interested in, or they just want to help<br>
you out personally.<br>
<br>
There aren't many Nova developers that use the vmware driver, so you've<br>
got to work on building karma with the team. That means contributing to<br>
other areas, which honestly, I haven't seen much of from this group. I<br>
think that would go a long way.<br></blockquote><div><br></div><div>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 <a href="https://bugs.launchpad.net/nova/+bugs?field.tag=low-hanging-fruit">https://bugs.launchpad.net/nova/+bugs?field.tag=low-hanging-fruit</a> still the best place for them to look? Doesn't seem to be much there that isn't already in progress. </div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I think if you review the history of vmware patches, you'll see my name<br>
as a reviewer on many (or perhaps most) of them, so I hope nobody thinks<br>
that I personally am trying stall things here. This is just based on my<br>
experience across all contributions.<br></blockquote><div><br></div><div>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 :) </div>
<div><br></div><div style>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. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I already put a session on the design summit schedule to discuss the<br>
future of drivers. I'm open to alternative approaches for driver<br>
maintenance, including moving some of them (such as the vmware driver)<br>
into another tree where the developers focused on it can merge their<br>
code without waiting for nova-core review.<br>
<br>
<a href="http://summit.openstack.org/cfp/details/4" target="_blank">http://summit.openstack.org/cfp/details/4</a></blockquote><div><br></div><div style>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. </div>
<div style><br></div><div style>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. </div>
<div><br></div><div style><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
<span><font color="#888888"><br>
--<br>
Russell Bryant<br>
</font></span><div><div><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>Dan Wendlandt <div>Nicira, Inc: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><br><div>twitter: danwendlandt<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br></div></div>
</div></div></div>