<div dir="ltr">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:<div><br></div><div>  Nova is a complex beast, very few people know even most of it well.</div><div>  There are areas of Nova where mistakes are costly and hard to rectify later.<div>  A large amount of good code does not merge quickly.</div><div>  The pool of active core reviewers is very much smaller than the total pool of contributors.</div><div>  The barrier to entry for Nova core is very high.<br></div><div><br></div><div>There was more, but I think most people agreed on the above.</div><div><br></div><div>Just before summit I pitched a subsystem maintainer model here:</div><div>  <a href="http://lists.openstack.org/pipermail/openstack-dev/2016-September/104093.html">http://lists.openstack.org/pipermail/openstack-dev/2016-September/104093.html</a><br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>I'd like to re-iterate that what I'd personally like to achieve is:</div><div><br></div><div>  "Good code should merge quickly."</div><div><br></div><div>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.</div><div><br></div><div>Thanks,</div><div><br></div><div>Matt<br>-- </div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><span style="font-size:12.8px">Matthew Booth</span><br></div><div>Red Hat Engineering, Virtualisation Team</div><div><br></div><div>Phone: +442070094448 (UK)</div><div><br></div></div></div></div></div>
</div></div>