On Fri, Sep 20, 2013 at 1:58 PM, Joe Gordon <[email protected]> wrote:
> > On Sep 20, 2013 1:27 PM, "Dan Wendlandt" <[email protected]> wrote: > > > > > > > > > > On Fri, Sep 20, 2013 at 1:09 PM, Joe Gordon <[email protected]> > wrote: > >> > >> 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. > > > > > > > > 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. > Great. By the way, all of this automated tempest testing is running nested on top of a physical OpenStack on vSphere cloud we run internally. That cloud has the ability to host "labs" that are externally accessible. So if you're a core Nova reviewer (or other person who does a lot of Nova reviews), I could definitely look into how we can get you access to a devstack + vSphere environment for your personal use of reviewing + testing patches. Anything I can do to make a core reviewers life easier here, I'm all for. Feel free to reach out to me off-list. 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 > >>> [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 > >> > > > > > > > > -- > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Dan Wendlandt > > Nicira, Inc: www.nicira.com > > twitter: danwendlandt > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > _______________________________________________ > > 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 > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
