Participants: David Ostrovsky [DO], Hari Jeyamani [HJ], Ivan Frade [IF], Luca Milanesio [LM], Matthias Sohn [MS], Nasser Grainawi [NG], Saša Živkov [SZ]

Next meeting: TBC, pending next forthcoming ESC elections in June.

Executive Summary

The ESC is evaluating changing the “AI Review” feature to a default-deny model to meet enterprise IP requirements, while also drafting new guidelines that require contributors to tag AI-generated submissions. To address ongoing dependency conflicts between Gerrit and JGit, we will maintain specific “fork” branches within our JGit mirror and are planning a secure, non-intrusive upgrade to Jetty 12. Operationally, [HJ] is succeeding [IF] on the ESC as we continue our search for a dedicated community manager.

Gerrit Engineering Steering Committee (ESC) Meeting Summary

1. AI Review Permission Logic

Background

The “AI Review” feature initially launched without permissions as it functioned purely as a text prompt generator based on code diffs, consuming no backend resources.

Issue and Possible Solutions

Large organizations in critical sectors require strict control over data sharing with AI to comply with information security standards. Currently, permissions are enabled by default to suit Google’s internal workflow. However, this contradicts Gerrit’s standard default-deny semantics and prevents community users from complying with internal company policies.

The introduction of an “AI Review” permission allows administrators to use “deny” or “block” ACLs. [HJ] will check internally at Google if the permission model can be flipped to a default-deny to align with other Gerrit ACLs. [DO] has already proposed a change for this switch, including the necessary schema migration.

2. Dependency Misalignment: JGit and Gerrit

There is a growing divergence between Gerrit (Google) and JGit (Eclipse Foundation). Google strictly enforces identical dependencies across its projects (e.g., retaining Java EE and Servlet-4), while Eclipse follows standard industry update cycles (e.g., migrating to Jakarta EE and Servlet-6).

This misalignment causes significant maintenance hurdles, preventing the use of stable JGit branches for fixes in older stable Gerrit releases (v3.12 and v3.13).

Since migrating Google’s frameworks to the Jakarta namespace is currently not feasible, Gerrit will remain on Servlet-4.

3. Jetty 9 Deprecation Strategy

Gerrit currently uses Jetty 9, which is discontinued and lacks security updates.

[DO] proposed a non-intrusive upgrade to Jetty 12. Crucially, this upgrade would maintain the Servlet-4 “javax” namespace to avoid breaking other dependencies. [IF] will evaluate internal Google code to check the feasibility of this upgrade path.

4. JGit Forking Strategy & Logistics

To manage the dependency misalignment, [MS] proposed creating specific “fork” branches within the Gerrit Review JGit mirror (gerrit.googlesource.com/jgit). This handles version mismatches without imposing maintenance burdens on the upstream Eclipse repository.

5. AI Usage Guidelines for Contributions

[LM] highlighted that recent security reports were potentially generated by AI without the submitters fully understanding the technical content, raising traceability and quality concerns.

The committee discussed implementing guidelines requiring contributors to tag AI-generated work. [HJ] will research existing internal Google guidance for open-source projects to establish a consistent, responsible policy.

6. ESC and Google Leadership Updates

[HJ] is succeeding [IF] in the ESC leadership role, with [IF] remaining available as a backup.

Community Manager: The search for a dedicated community manager continues to ensure there is no conflict of interest between corporate and community priorities.

ESC Meeting Action Items

  • [HJ] Check internally at Google if the “AI Review” permission model can be flipped to a default-deny configuration to align with standard Gerrit ACLs.
  • [IF] Evaluate internal Google code to determine the feasibility of upgrading to Jetty 12 while retaining the Servlet-4 “javax” namespace.
  • [HJ] & [IF] Investigate the feasibility of creating JGit “fork” branches on the Gerrit Review mirror (gerrit.googlesource.com/jgit) and manage GerritHub.io mirror policies accordingly.
  • [Googlers / LM] Adjust internal replication jobs to allow pushing to the new specific JGit fork branches.
  • [ESC Team] Ensure that the new JGit fork branches are clearly documented in the release notes to maintain community transparency.
  • [HJ] Research existing internal Google guidance for open-source projects to help draft a policy requiring contributors to tag AI-generated submissions.
  • [HJ] Continue the search for a dedicated community manager to prevent conflicts of interest.