<div dir="ltr">Jeremy, <div><br></div><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"><br><span style="font-size:12.8000001907349px"> the Infrastructure Project is now past 120 repos with more<br></span><span style="font-size:12.8000001907349px">than 70 core reviewers among those.</span></blockquote><div><div><br></div><div>I dislike the idea of having 120 repos for single tool. It makes things complicated for everybody: </div><div>documentation stuff, installation, maintaing, work that touches multiple repos and so on.. </div><div><br></div><div>So I would prefer to have single repo with many subcores. </div><div><br></div><div><br></div><div>Robert, </div><div><br></div><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">We *really* don't need a technical solution to a social problem.</span></blockquote><div><br></div><div>We really need... It's like non voting jobs in our CI (everybody just ignores). </div><div>Btw it will be hard for large core team to know each other. </div><div>Especially if we are speaking about various groups of cores that are mantaining</div><div>only parts of systems. Keeping all this in heads will be hard task (it should be automated)  </div><div><br></div><div><br></div><div>Best regards,</div><div>Boris Pavlovic </div><div> </div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 3, 2015 at 2:12 AM, Robert Collins <span dir="ltr"><<a href="mailto:robertc@robertcollins.net" target="_blank">robertc@robertcollins.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 3 June 2015 at 10:34, Jeremy Stanley <<a href="mailto:fungi@yuggoth.org">fungi@yuggoth.org</a>> wrote:<br>
> On 2015-06-02 21:59:34 +0000 (+0000), Ian Cordasco wrote:<br>
>> I like this very much. I recall there was a session at the summit<br>
>> about this that Thierry and Kyle led. If I recall correctly, the<br>
>> discussion mentioned that it wasn't (at this point in time)<br>
>> possible to use gerrit the way you describe it, but perhaps people<br>
>> were mistaken?<br>
> [...]<br>
><br>
> It wasn't an option at the time. What's being conjectured now is<br>
> that with custom Prolog rules it might be possible to base Gerrit<br>
> label permissions on strict file subsets within repos. It's<br>
> nontrivial, as of yet I've seen no working demonstration, and we'd<br>
> still need the Infrastructure Team to feel comfortable supporting it<br>
> even if it does turn out to be technically possible. But even before<br>
> going down the path of automating/enforcing it anywhere in our<br>
> toolchain, projects interested in this workflow need to try to<br>
> mentally follow the proposed model and see if it makes social sense<br>
> for them.<br>
><br>
> It's also still not immediately apparent to me that this additional<br>
> complication brings any substantial convenience over having distinct<br>
> Git repositories under the control of separate but allied teams. For<br>
> example, the Infrastructure Project is now past 120 repos with more<br>
> than 70 core reviewers among those. In a hypothetical reality where<br>
> those were separate directory trees within a single repository, I'm<br>
> not coming up with any significant ways it would improve our current<br>
> workflow. That said, I understand other projects may have different<br>
> needs and challenges with their codebase we just don't face.<br>
<br>
</div></div>We *really* don't need a technical solution to a social problem.<br>
<br>
If someone isn't trusted enough to know the difference between<br>
project/subsystemA and project/subsystemB, nor trusted enough to not<br>
commit changes to subsystemB, pushing stuff out to a new repo, or<br>
in-repo ACLs are not the solution. The solution is to work with them<br>
to learn to trust them.<br>
<br>
Further, there are plenty of cases where the 'subsystem' is<br>
cross-cutting, not vertical - and in those cases its much much much<br>
harder to just describe file boundaries where the thing is.<br>
<br>
So I'd like us to really get our heads around the idea that folk are<br>
able to make promises ('I will only commit changes relevant to the DB<br>
abstraction/transaction management') and honour them. And if they<br>
don't - well, remove their access. *even with* CD in the picture,<br>
thats a wholly acceptable risk IMO.<br>
<br>
-Rob<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>
Distinguished Technologist<br>
HP Converged Cloud<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>