[openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)
Joshua Harlow
harlowja at outlook.com
Wed Jun 3 20:22:50 UTC 2015
Jeremy Stanley wrote:
> On 2015-06-03 11:45:57 -0700 (-0700), Joshua Harlow wrote:
> [...]
>> If boris (and friends) will make the needed changes to jenkins or
>> other to have whatever ACL format (avoid a turing complete
>> language please)
> [...]
>
> The proposal is to introduce Prolog into the Gerrit ACLs to match on
> file patterns; that's why I referred to "a turing complete
> language." These would necessarily be baked into each project's ACL
> that needed to use them, and would be up to the Infra project-config
> reviewers to review any time the directory structure within a
> project changes and impacts the per-project custom scripting
> required to support it.
Sounds overly complex for a bunch of regex filters.
---
.coder_acls (even place this in the repo itself?)
/rally
- rally-core
/rally/code/*
- rally-code-core
/rally/blah-blah/*
- rally-blah-blah-core
I don't know if thats easy or not, but prolog seems like way overkill.
>
> This was already discussed in IRC and the Infra PTL suggested to
> "dry-run" the model before dragging in new parts of Gerrit we've not
> been using yet. The suggestion was to start a mailing list thread to
> see if other projects had similar conceptual models they were
> following so as to try and build consensus, not to appeal to the
> community in an attempt to get them to counter our advice about
> throwing new technical solutions at a problem (and necessarily
> increasing the burden on us) before figuring out if it even makes
> sense as something we should spend our limited person-hour resources
> supporting.
Understood, although maybe this model will work for rally (and if boris
does most of the gerrit work, that's great to). I don't feel like
consensus will happen here, and that really what needs to happen is an
experiment with results (did it or didn't it work out for rally). If it
does, that's great, if it doesn't, that's great to (lessons learned). I
start to feel that always trying to reach consensus on everything
(especially when this is new territory, that may work out just fine for
rally in the end...) limits the span of what the community can envision,
and without a ability to think outside of the box or let others try
experiments that broaden all of our horizons, we are dead in the water
(overly dramatic I know)...
>
> Keep in mind, we went into the Liberty Design Summit with plenty of
> backlog, and came out with even more priorities to tackle. Is
> support for this something the community would like to see us
> spending our time on _instead_ of some of those other priorities?
Maybe others not in infra can do most of the work? If we have issues
scaling the infra team (do we?), that might just be a different issue
that this rally request is scratching the surface of that should be
brought up and resolved?
-Josh
More information about the OpenStack-dev
mailing list