<div dir="ltr">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><div class="gmail_extra"><div class="gmail_quote">
<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></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>I while back Russell announced we would like all virt drivers have a public functional testing system by the release of Icehouse (<a href="http://lists.openstack.org/pipermail/openstack-dev/2013-July/011280.html">http://lists.openstack.org/pipermail/openstack-dev/2013-July/011280.html</a>). 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 (<a href="https://wiki.openstack.org/wiki/HypervisorSupportMatrix" target="_blank">https://wiki.openstack.org/wiki/HypervisorSupportMatrix</a> -- "<span style="color:rgb(51,51,51);font-family:'Arial Unicode MS',Arial,sans-serif;font-size:14px;line-height:20px">These drivers have minimal testing and may or may not work at any given time. Use them at your own risk")</span> 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.</div>
<div><br></div><div><br></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"><div>
><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><br>
<br>
Right now we're running a bit behind the set goal of keeping the average<br>
under 5 days for the latest revision (1st set of numbers), and 7 days<br>
for the oldest revision since the last -1 (3rd set of numbers).<br>
However, Nova is now (and has been since I've been tracking this) below<br>
the average for all OpenStack projects:<br>
<br>
<a href="http://russellbryant.net/openstack-stats/all-openreviews.html" target="_blank">http://russellbryant.net/openstack-stats/all-openreviews.html</a><br>
<br>
Review prioritization is not something that I or anyone else can<br>
strictly control, but we can provide tools and guidelines to help. You<br>
can find some notes on that here:<br>
<br>
<a href="https://wiki.openstack.org/wiki/Nova/CoreTeam#Review_Prioritization" target="_blank">https://wiki.openstack.org/wiki/Nova/CoreTeam#Review_Prioritization</a><br>
<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>
<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>
<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><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></div></div>