Engineering Steering Committee Meeting, Jan 12, 2022

Christophe Poucet, Han-Wen Nienhuys, Luca Milanesio, Matthias Sohn, Patrick Hiesel, Saša Živkov.

Next meeting

Feb 2, 2022


Proposal to drop Log4J completely and use java.util.logging

Google does not use Log4J, and Gerrit does not require it directly because it is based on Flogger. Can we drop Log4J altogether in Gerrit?

After an initial analysis, it looks like some of the components that Gerrit uses (e.g., Apache Mina SSHD) still refer to Log4J directly; therefore, removing it won’t be trivial.

Matthias pointed out that the reload4j project ( has fixed the vulnerabilities found on Log4J 1.x and made the fork available to the community with the same Open-Source license.

The removal of Log4J is put on hold, waiting to see if the reload4j project may work in the meantime.

Definition of a policy for updating JGit on stable Gerrit branches

Gerrit and JGit have different release schedules: twice a year for Gerrit, four times a year for JGit. Also, there is reluctance in updating JGit pointer in Gerrit stable not-EOL branches because of the fear of potential regressions. The two factors have contributed to the accumulation of lag in the alignment of the latest JGit version in Gerrit. For example, both Gerrit v3.4 and v3.5 use JGit v5.12, six months behind the latest.

The consensus is to define a policy for updating JGit pointer on a regular basis as follows: Gerrit/master updates its submodule to JGit/master regularly. After two weeks of tests by Google (using the JGit fork) and GerritForge (using the JGit vanilla), the update is performed on the non-EOL stable branches, assuming that there are no breaking JGit API changes. Stable branches that are in EOL will not have any regular JGit updates

Delay in Gerrit releases due to the review of release notes

The Gerrit release notes are created and reviewed too late in the process, causing potential delays and potential mistakes and gaps in the initial Gerrit versions. Ideally, updating the release notes should be part of the review process of the changes that are modifying or creating new functionalities, rather than a one-off task for the release manager.

We had the idea of implementing the mechanism of validating the presence of release notes in the submit rules; however, that did not take off. Patrick takes the task of assessing a similar check by using the new submit requirements available in Gerrit master.

Proposal to drop Java-8 support for stable-3.3/3.4

Gerrit v3.3.* and v3.4.* are distributed only for Java 11; however, during their development SAP and Google needed to preserve the source-code compatibility to Java 8 for being able to upgrade and deploy to their respective Java 8-based setup. Nowadays, SAP and Google are on Java 11; therefore, there is no need anymore to keep source-code level compatibility with Java 8.

The consensus is to drop Java 8 source compatibility for stable-3.3/3.4 to switch the whole Gerrit CI/CD pipeline to Java 11, avoiding complicated if/then/else in the build scripts.

Luca has created a small survey for asking the community which Java version is used with Gerrit v3.3/v3.4. Once the results are available, the project can make a final decision on the matter.

Proposal to define a trusted group of contributors for running CI builds

Currently, any incoming Gerrit change triggers a CI build, posing security risks because the execution happens before any review or validation by contributors. Both the Jenkins-based pipeline ( and the Zuul pipeline ( are impacted but with different security issues.

The use of RBE for the build execution would not mitigate the security issue, because some of the build steps have to be executed on the agents anyway (e.g., PolyGerrit tests).

The possible options are introducing further isolation layers (e.g., or using a service such as Google Cloud Build. Han-Wen will explore this second option.