[openstack-dev] Fixing the Nova Core Reviewer Frustration [was Re: [Nova] PTL Candidacy]

Joe Gordon joe.gordon0 at gmail.com
Tue Apr 7 19:52:42 UTC 2015

On Tue, Apr 7, 2015 at 10:02 AM, James Bottomley <
James.Bottomley at hansenpartnership.com> wrote:

> On Tue, 2015-04-07 at 11:27 +1000, Michael Still wrote:
> > Additionally, we have consistently asked for non-cores to help cover
> > the review load. It doesn't have to be a core that notices a problem
> > with a patch -- anyone can do that. There are many people who do help
> > out with non-core reviews, and I am thankful for all of them. However,
> > I keep meeting people who complain about review delays, but who don't
> > have a history of reviewing themselves. That's confusing and
> > frustrating to me.
> I can understand why you're frustrated, but not why you're surprised:
> the process needs to be different.  Right now the statement is that for
> a patch series to be accepted it has to have a positive review from a
> core plus one other, however the "one other" can be a colleague, so it's
> easy.  The problem, as far as submitters see it, is getting that Core
> Reviewer.  That's why so much frenzy (which contributes to your
> frustration) goes into it.  And why all the complaining which annoys
> you.
> To fix the frustration, you need to fix the process:  Make the cores
> more of a second level approver rather than a front line reviewer and I
> predict the frenzy to get a core will go down and so will core
> frustration.  Why not require a +1 from one (or even more than one)
> independent (for some useful value of independent) reviewer before the
> cores will even look at it?  That way the cores know someone already
> thought the patch was good, so they're no longer being pestered to
> review any old thing and the first job of a submitter becomes to find an
> independent reviewer rather than go bother a core.

++, I actually already prefer to focus my reviews on patches that already
have a +1.

We have been using a trivial patch monkey process (see the bottom of
https://etherpad.openstack.org/p/kilo-nova-priorities-tracking) that is
similar to this with great results already.

> James
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150407/ade4de40/attachment.html>

More information about the OpenStack-dev mailing list