[openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

Robert Collins robertc at robertcollins.net
Wed Jun 3 18:21:12 UTC 2015


On 4 June 2015 at 02:51, Jeremy Stanley <fungi at yuggoth.org> wrote:
> On 2015-06-03 17:15:43 +0300 (+0300), Boris Pavlovic wrote:
>> I can't talk for other projects, so let's talk about Rally specific.
>>
>> We have single .git in root for whole project.
>>
>> We have 4 subdir that can have own maintainers:
>> - rally/deploy
>> - rally/verify
>> - rally/benchmark
>> - rally/plugins
>>
>> First 3 subdir are quite different and usually isolated communities.
>> Plugins are not so hard to review and mostly developed part.
>>
>> If I would be able to have cores for specific areas that will scale up
>> code reviewing process a lot
>> without any trust, process, social, arch, whatever changes in project.
>
> I get that, but if you already have rally/deploy, rally/verify and
> rally/benchmark as separate directory trees then why not just git
> filter-branch those into new repos and add dedicated review teams to
> them? That doesn't involve any "rearchitecting" since they're
> already effectively split up and just happen to coexist in one repo
> today.

Some of the the consequences of splitting up repos:
 - atomic changes become non-atomic
 - cross-cutting changes become more complex
 - code analysis has to deal with more complex setups (can't lint
across boundaries as readily, for instance)
 - distribution and installation via source become harder
 - project mgmt overheads increase
 - project identity becomes more amorphous

These aren't necessarily bad things, but they are things, and since
the purported goal is to reduce the likelyhood of defects entering
rally's codebase, I'd be wary of those consequences.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud



More information about the OpenStack-dev mailing list