On Fri, Sep 20, 2013 at 1:09 PM, Joe Gordon <joe.gord...@gmail.com> wrote:
> On Fri, Sep 20, 2013 at 11:52 AM, Russell Bryant <rbry...@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. > Hi Joe, I couldn't agree more. In fact, the VMware team has been working hard to get a fully-automated CI infrastructure setup and integrated with upstream Gerrit. We already run the tempest tests internally and have been manually posting tempest results for some patches. I wouldn't want to speak for the dev owner, but I think within a very short time (before Havana) you will begin seeing automated reports for tempest tests on top of vSphere showing up on Gerrit. I agree that this will really help core reviewers gain confidence that not only does the code "look OK", but that it works well too. Dan > > > > >> > 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@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
