[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