On Wed, May 22, 2019 at 03:18:36PM +0000, Jeremy Stanley wrote:
On 2019-05-22 09:26:19 +0100 (+0100), Stephen Finucane wrote: [...]
I realize this is bound to be controversial, but would it be possible to just auto-merge these patches assuming they pass CI? We've had a lot of these initiatives before and, invariably, there are some projects that won't get around to merging these for a long time (if ever). We had to do this recently with the opendev updates to the '.gitreview' files (I think?) so there is precedent here.
Well, there were two approaches we used in the OpenDev migration:
1. Backward-compatible mass changes which fixed things we knew would otherwise break were proposed, given a brief opportunity for projects to review and approve or -2, and then at an pre-announced deadline any which were still open but passing their jobs and had no blocking votes were bulk-approved by a Gerrit administrator who temporarily elevated their access to act as a core reviewer for all projects. More specifically, this was the changes to replace git:// URLs with https:// because we were dropping support for the protocol.
2. Non-backward-compatible mass changes which fixed things we knew would otherwise be broken by the transition were committed directly into the on-disk copies of repositories in Gerrit while the service was offline for maintenance, entirely bypassing CI and code review. These were changes for things like .gitreview files and zuul pipelines/jobs/playbooks/roles.
Yeah clearly not this one ;P
I think something similar to #1 might be appropriate here. I could see, for example, requiring Gerrit ACLs for official OpenStack deliverable repositories to inherit from a parent ACL (Gerrit supports this) which includes core reviewer permissions for a group that the Release team can temporarily add themselves to,
We could use "Project Bootstrappers" for this, which I think has all the right permissions. It would be a matter of adding the right people to that group for a short period of time. It'd be the requirements team rather than release team.
for the purposes of bulk approving relevant changes at or shortly following the coordinated release. The release process they follow already involves some automated group updates for reassigning control of branches, so this probably wouldn't be too hard to incorporate.
We could add a group similar to "Project Bootstrappers" but with slightly fewer permissions if we think using this approach from time-to-time is an acceptable idea. Yours Tony.