[openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)
boris at pavlovic.me
Wed Jun 3 14:15:43 UTC 2015
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:
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.
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
> 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
> > 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...
More information about the OpenStack-dev