<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 2, 2015 at 4:12 PM, 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></blockquote><div><br></div><div>With gerrit's great REST APIs it would be very easy to generate a report to detect if someone breaks their promise and commits something outside of a given sub-directory.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></div>