On Mon, 2016-11-07 at 11:50 +0000, Matthew Booth wrote: > 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/1 > 04093.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.
I'm just going to leave this here... https://github.com/torvalds/linux/blob/master/MAINTAINERS http://dpdk.org/browse/dpdk/tree/MAINTAINERS We probably don't want to/can't go down the path of hard subtrees (though we might be already simulating that with the various 'os-' projects). I do imagine, however, that most folks who have been working on nova for long enough have a list of domain experts in their heads already. Would actually putting that on paper really hurt? Stephen __________________________________________________________________________ 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
