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 <jul...@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 */ >
__________________________________________________________________________ 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
