Open Stack

I'd like to follow up on the discussions we had in Barcelona around review
cadence. I took a lot away from these discussions, and I thought they were
extremely productive. I think the summary of the concerns was:

  Nova is a complex beast, very few people know even most of it well.
  There are areas of Nova where mistakes are costly and hard to rectify
later.
  A large amount of good code does not merge quickly.
  The pool of active core reviewers is very much smaller than the total
pool of contributors.
  The barrier to entry for Nova core is very high.

There was more, but I think most people agreed on the above.

Just before summit I pitched a subsystem maintainer model here:

http://lists.openstack.org/pipermail/openstack-dev/2016-September/104093.html

Reading over this again, I still think this is worth trialling: it pushes
the burden of initial detailed review further out, whilst ensuring that a
core will still check that no wider issues have been missed. Bearing in
mind that the primary purpose is to reduce the burden on core reviewers of
any individual patch, I think this will work best if we aggressively push
initial review down as far as possible.

I'm still not sure what the best description of 'domain' is, though. Other
projects seem to have defined this as: the reviewer should, in good faith,
know when they're competent to give a +2 and when they're not. I suspect
this is too loose for us, but I'm sure we could come up with something.

I'd expect the review burden of a maintainer of an active area of code to
be as heavy as a core reviewer's, so this probably shouldn't be taken
lightly. If we were to trial it, I'd also recommend starting with a small
number of maintainers (about 3, perhaps), preferably technical-leaders of
active sub-teams. Any trial should be the topic of a retrospective at the
PTG.

I'd like to re-iterate that what I'd personally like to achieve is:

  "Good code should merge quickly."

There are likely other ways to achieve this, and if any of them are better
than this one then I'm in favour. However, I think we can try this one with
limited risk and initial up-front effort.

Thanks,

Matt
-- 
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161107/7cb82ba4/attachment.html>