Open Stack

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190523/4cb5defc/attachment.sig>