Open Stack

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