...

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. 

...

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, Linux Foundation Release Engineering (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 in and push it to the project's Gerrit server and potentially make a correction on the LF GerritLinux Foundation's Gerrit or LDAP Linux Foundation Account groups side.

Recommended policy change

+1/-1 Vote should be granted on demand basis via https://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. 

...

By allowing only Jenkins to verify the sanity of a Gerrit change, we can potentially allow for fully 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. , or other automated processes that rely on accurate validation of proposed changes.