[openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

Robert Collins robertc at robertcollins.net
Tue Jun 2 23:12:35 UTC 2015

On 3 June 2015 at 10:34, Jeremy Stanley <fungi at 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.


Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud

More information about the OpenStack-dev mailing list