On Fri, Sep 20, 2013 at 11:52 AM, Russell Bryant <[email protected]> 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. > > > 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
