Current status

Currently all ONAP Gerrit project owners (committers for each repo) have the ability to vote +1/-1 Label Verified and overwrite the

Jenkins vote if there is any automation job running on a given Gerrit change. 

Impact

If CI Jenkins fails to verify a change (by voting -1 Label Verified), owners still have the choice to overwrite the -1 Vote with a +1

and allow the change to be merged potentially breaking further CI processes.

When processes break due to a bad merge, RelEng has to debug and find the real build cause and the issue in the code that needs to

be fixed. When dealing with releases, this can lead to automation not being able to proceed on its own and needed intervention to

manually correct and make a release. When dealing with committer changes, manual intervention is needed to correct the change in 

and push it to the project's Gerrit server and potentially make a correction on the LF Gerrit's or LDAP groups side.

Recommended policy change

+1/-1 Vote should be granted on demand basis via support.linuxfoundation.org with TSC approval and explanation on why the permission is needed.

This vote should be allowed in cases where the team is working on a new code bring up and there is no Jenkins jobs available that can verify the code or

in cases where CI services are failing due to an infrastructure issue blocking the changes from being verified. 

Benefits

By allowing only Jenkins to verify the sanity of a Gerrit, we can potentially allow for automatic merges when it comes to INFO.yaml committer changes

and further explore more automation behind release files. We will need to make sure Jenkins is able to catch any potential issue and flag it properly

when is met to get to a point where we can trust Jenkins to verify fully the change for us.