[OpenStack-Infra] Fwd: RFC: Workflow for gerrit security patches
Zaro
zaro0508 at gmail.com
Mon Oct 7 18:31:02 UTC 2013
Hello,
We are getting close to standing up a private gerrit instance for security
reviews (https://bugs.launchpad.net/openstack-ci/+bug/1083101). As
mentioned in the bug our plan is to run a second gerrit to facilitate code
review for embargoed patches. But we will not run an entire second shadow
environment (too much effort for ~50 patches a year).
A few of the implementation details were unclear so I would like to make a
proposal and get feedback before continuing to work on the bug.
A few members of infra team had a discussion on the workflow and fungi
proposed the following..
1. git clone from security gerrit (review-security.o.o)
2. git review patch to security gerrit
3. The patch is review-able by vmt member, change owner and any manually
added reviewer.
4. patch is reviewed and approved on review-security.o.o
5. patch is copied from security gerrit to public gerrit..
a. git review -d from review-security.o.o
b*. git review to review.o.o
*Note - security review information (votes/notes/etc..) will not get copied
to review.o.o
Does this seem like the right workflow for approving and integrating
security patches?
We are also proposing that, instead of syncing accounts from public gerrit
to security gerrit, we shoud keep the accounts independent for the
following reasons:
1. It would make it a little harder to unintentionally push to the wrong
gerrit.
2. Some people might want to configure their account profiles differently
on each gerrit (something like project watches).
3. It will minimize the potential for leakage.
4. Syncing accounts requires more management overhead.
With the above proposals we would replicate the gerrit git repository from
review.o.o to review-security.o.o but NOT the gerrit database.
Does anyone have any objections to the above proposals? Further questions
are also welcome.
-Khai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20131007/2a422ae9/attachment.html>
More information about the OpenStack-Infra
mailing list