On 09/20/2013 01:24 PM, Dan Wendlandt wrote: > > > > On Fri, Sep 20, 2013 at 1:09 PM, Joe Gordon <joe.gord...@gmail..com > <mailto:joe.gord...@gmail.com>> wrote: > > On Fri, Sep 20, 2013 at 11:52 AM, Russell Bryant <rbry...@redhat.com > <mailto: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.
WOOT! > > 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 > <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 > <http://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 > <mailto:OpenStack-dev@lists.openstack.org> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > <mailto:OpenStack-dev@lists.openstack.org> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Dan Wendlandt > Nicira, Inc: www.nicira.com <http://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
