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. 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, 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. -- Jeremy Stanley