On Tue, Jun 2, 2015 at 4:12 PM, Robert Collins <robe...@robertcollins.net>
wrote:
> On 3 June 2015 at 10:34, Jeremy Stanley <fu...@yuggoth.org> wrote:
> > On 2015-06-02 21:59:34 +0000 (+0000), Ian Cordasco wrote:
> >> I like this very much. I recall there was a session at the summit
> >> about this that Thierry and Kyle led. If I recall correctly, the
> >> discussion mentioned that it wasn't (at this point in time)
> >> possible to use gerrit the way you describe it, but perhaps people
> >> were mistaken?
> > [...]
> >
> > It wasn't an option at the time. What's being conjectured now is
> > that with custom Prolog rules it might be possible to base Gerrit
> > label permissions on strict file subsets within repos. It's
> > nontrivial, as of yet I've seen no working demonstration, and we'd
> > still need the Infrastructure Team to feel comfortable supporting it
> > even if it does turn out to be technically possible. But even before
> > going down the path of automating/enforcing it anywhere in our
> > toolchain, projects interested in this workflow need to try to
> > mentally follow the proposed model and see if it makes social sense
> > for them.
> >
> > It's also still not immediately apparent to me that this additional
> > complication brings any substantial convenience over having distinct
> > Git repositories under the control of separate but allied teams. For
> > example, the Infrastructure Project is now past 120 repos with more
> > than 70 core reviewers among those. In a hypothetical reality where
> > those were separate directory trees within a single repository, I'm
> > not coming up with any significant ways it would improve our current
> > workflow. That said, I understand other projects may have different
> > needs and challenges with their codebase we just don't face.
>
> We *really* don't need a technical solution to a social problem.
>
> If someone isn't trusted enough to know the difference between
> project/subsystemA and project/subsystemB, nor trusted enough to not
> commit changes to subsystemB, pushing stuff out to a new repo, or
> in-repo ACLs are not the solution. The solution is to work with them
> to learn to trust them.
>
> Further, there are plenty of cases where the 'subsystem' is
> cross-cutting, not vertical - and in those cases its much much much
> harder to just describe file boundaries where the thing is.
>
> So I'd like us to really get our heads around the idea that folk are
> able to make promises ('I will only commit changes relevant to the DB
> abstraction/transaction management') and honour them. And if they
> don't - well, remove their access. *even with* CD in the picture,
> thats a wholly acceptable risk IMO.
>
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.
>
> -Rob
>
> --
> Robert Collins <rbtcoll...@hp.com>
> Distinguished Technologist
> HP Converged Cloud
>
> __________________________________________________________________________
> 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
>
__________________________________________________________________________
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
