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)
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
