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

Boris Pavlovic boris at pavlovic.me
Wed Jun 3 14:15:43 UTC 2015


Jeremy,


Except that reorganizing files in a repo so that you can have sane
> pattern matches across them for different review subteams is
> _exactly_ this. The question is really one of "do you have a
> separate .git in each of the directory trees for your subteams or
> only one .git in the parent directory?"


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.


Best regards,
Boris Pavlovic


On Wed, Jun 3, 2015 at 5:00 PM, Julien Danjou <julien at danjou.info> wrote:

> On Wed, Jun 03 2015, Boris Pavlovic wrote:
>
> > And I don't understand "what" so serious problem we have.
> > We were not able to do reverts so  we build CI that doesn't allow us to
> > break master
> >  so we don't need to do reverts. I really don't see here any big
> problems.
>
> Doing revert does not mean breaking nor unbreaking master. It's just
> about canceling changes. You're not able to break master if you have a
> good test coverage – and I'm sure Rally has.
>
> > I was talking about reverting patches. And I believe the process is
> broken
> > if you need to revert patches. It means that core team is not enough team
> > or CI is not enough good.
>
> Sure, reverting a patch means that a mistake has been made somewhere,
> *but* the point is that having a few mistakes done and reverted is far
> less a problem than freezing an entire project because everyone fears a
> mistake might be made. Just learn to make mistake, fix/revert them, and
> change fast. Not freeze everyone in terror of something being done. :)
>
> --
> Julien Danjou
> /* Free Software hacker
>    http://julien.danjou.info */
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150603/4f282ffd/attachment.html>


More information about the OpenStack-dev mailing list