On Sep 20, 2013 1:27 PM, "Dan Wendlandt" <d...@nicira.com> wrote: > > > > > 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
Awesome, when that happens I hope to review more vmwareapi patches. Part of the trick will be in how I can see that after a nova patch is merged the vmwareapi system will cover that case going forward. > > > > > > >> >> >> >>> > >>> > 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 >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev