[openstack-dev] doubling our core review bandwidth
Zane Bitter
zbitter at redhat.com
Mon Sep 8 17:54:42 UTC 2014
On 07/09/14 23:43, Morgan Fainberg wrote:
>> ## avoiding collaboration between bad actors
>> >
>> >The two core requirement means that it takes three people (proposer +
>> >2 core) to collaborate on landing something inappropriate (whether its
>> >half baked, a misfeature, whatever). Thats only 50% harder than 2
>> >people (proposer + 1 core) and its still not really a high bar to
>> >meet. Further, we can revert things.
> Solid assessment. I tend to agree with this point. If you are going to have bad actors try and get code in you will have bad actors trying to get code in. The real question is: how many (if any) extra reverts will be needed in the case of bad actors? My guess is 1 per bad actor (which that actor is likely no longer going to be core), if there are even any bad actors out there.
I think this misses the point, which isn't so much to prevent bad actors
(and I don't think we have any of those). It's to protect good (and
sometimes maybe slightly misguided) actors from any perception that they
might be behaving as bad actors.
I think Rob missed another possible benefit off the list: it allows us
to add core team members more aggressively than we might if adding
someone meant allowing them to approve patches by themselves.
I'm not convinced that dropping the 2 x +2 is the right trade-off,
though I would definitely support more official documentation of the
wiggle room available for reviewer discretion, such as what Flavio
suggested. In Heat we agreed on a policy of allowing immediate approval
in the case where you're effectively reviewing a rebase of or a minor
fix to a patchset that already had the assent in principle of two core
reviewers. I rarely see anyone actually do it though, I think in part
because the OpenStack-wide documentation makes it sound very naughty. I
was interested to learn from this thread that many programs appear to
have informally instituted something similar.
cheers,
Zane.
More information about the OpenStack-dev
mailing list