Open Stack

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