<div dir="ltr"><div><span style="font-size:12.8000001907349px">Jeremy, </span></div><div><span style="font-size:12.8000001907349px"><br></span></div><span style="font-size:12.8000001907349px"><div><span style="font-size:12.8000001907349px"><br></span></div></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8000001907349px">Except that reorganizing files in a repo so that you can have sane<br></span><span style="font-size:12.8000001907349px">pattern matches across them for different review subteams is<br></span><span style="font-size:12.8000001907349px">_exactly_ this. The question is really one of "do you have a<br></span><span style="font-size:12.8000001907349px">separate .git in each of the directory trees for your subteams or<br></span><span style="font-size:12.8000001907349px">only one .git in the parent directory?"</span></blockquote><div><br></div><div>I can't talk for other projects, so let's talk about Rally specific. </div><div><br></div><div>We have single .git in root for whole project. </div><div><br></div><div>We have 4 subdir that can have own maintainers: </div><div>- rally/deploy</div><div>- rally/verify </div><div>- rally/benchmark </div><div>- rally/plugins</div><div><br></div><div>First 3 subdir are quite different and usually isolated communities. </div><div>Plugins are not so hard to review and mostly developed part.</div><div><br></div><div>If I would be able to have cores for specific areas that will scale up </div><div>code reviewing process a lot </div><div>without any trust, process, social, arch, whatever changes in project. </div><div><br></div><div><br></div><div>Best regards,</div><div>Boris Pavlovic  </div><div> </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 3, 2015 at 5:00 PM, Julien Danjou <span dir="ltr"><<a href="mailto:julien@danjou.info" target="_blank">julien@danjou.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Jun 03 2015, Boris Pavlovic wrote:<br>
<br>
</span><span class="">> And I don't understand "what" so serious problem we have.<br>
> We were not able to do reverts so  we build CI that doesn't allow us to<br>
> break master<br>
>  so we don't need to do reverts. I really don't see here any big problems.<br>
<br>
</span>Doing revert does not mean breaking nor unbreaking master. It's just<br>
about canceling changes. You're not able to break master if you have a<br>
good test coverage – and I'm sure Rally has.<br>
<span class=""><br>
> I was talking about reverting patches. And I believe the process is broken<br>
> if you need to revert patches. It means that core team is not enough team<br>
> or CI is not enough good.<br>
<br>
</span>Sure, reverting a patch means that a mistake has been made somewhere,<br>
*but* the point is that having a few mistakes done and reverted is far<br>
less a problem than freezing an entire project because everyone fears a<br>
mistake might be made. Just learn to make mistake, fix/revert them, and<br>
change fast. Not freeze everyone in terror of something being done. :)<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Julien Danjou<br>
/* Free Software hacker<br>
   <a href="http://julien.danjou.info" target="_blank">http://julien.danjou.info</a> */<br>
</font></span></blockquote></div><br></div>