On Tue, Apr 7, 2015 at 10:02 AM, James Bottomley < [email protected]> 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
