_posts/2021-01-15-esc-minutes.md

---
title: "Gerrit ESC Meeting Minutes"
tags: esc
keywords: esc minutes
permalink: 2021-01-15-esc-minutes.html
summary: "Minutes from the ESC meeting held on January 12th"
hide_sidebar: true
hide_navtoggle: true
toc: true
---

## Engineering Steering Committee Meeting, January 12, 2021

### Attendees

Ben Rohlfs, Han-Wen Nienhuys, Patrick Hiesel, Luca Milanesio, Saša Zivkov

### Place/Date/Duration

Online, January 12, 11:00 - 11:45 CET

### Next meeting

The next meeting will be held on February 2, 11:00 CEST.

## Minutes

### Gerrit long-term stable releases (LTS)

Should the Gerrit project start keeping long-term support branches for one or
more releases of Gerrit? The current [EOL policy](https://www.gerritcodereview.com/support.html#supported-versions)
defines an 18 months (3 releases) lifetime. Gerrit v2.16, released back in
November 2018, represents an exception and will be kept for longer to allow
existing pre-2.16 installations to migrate to Gerrit v3.x and beyond.

The proposal to an extended support cycle for some elected LTS releases has been
unanimously rejected for the following reasons:

- The LTS branch would need strong governance on what can and cannot be added. The code-base
  could diverge from the mainstream development and eventually become a _de-facto_ fork of Gerrit.

- Web-browsers may not have an LTS support policy aligned with Gerrit, causing compatibility
  issues and additional hurdles to support browser upgrades. E.g. Firefox Enterprise Edition support
  is limited to 1 year.

- The Gerrit Community focuses on helping to migrate to more recent and modern releases, such as v3.3
  with attention-set. Having an LTS release for 5-10 years would give further incentive
  for companies to shelf current upgrade plans.

 - Older versions of Gerrit have more issues with rough edges on the user experience, which people see
   and use to judge the product. Having more obsolete LTS versions of
   Gerrit around would bring even more bad PR to the product itself.

### Zuul for gerrit itself

The Gerrit Code Review project has started adopting [Zuul](https://zuul-ci.org/) from 2019/2020 and
it is now used for the build of a large number of plugins on the [Gerrit Zuul CI instance](https://ci.gerritforge.com).

Han-Wen proposed to extend the adoption of Zuul to the CI of Gerrit itself.
There is consensus to proceed, assuming that Zuul has bridged the gap for supporting Docker-based
build agents, instead of GCloud VMs. Luca will follow up with James (Zuul maintainer) to check
the status and plan the next steps.

### Status of dropping Java 8 support for Gerrit

Google is planning to move to Java 11 in H2/2021, allowing to drop the support for Java 8 build
validation on Gerrit master. The target release for dropping Java 8 is therefore Gerrit v3.5, while
Gerrit v3.4 will continue to support Java 8 compilation.

### What's cooking in GerritForge for 2021

Luca shared the [GerritForge’s shopping list for 2021](https://gitenterprise.me/2021/01/04/2021-whats-cooking-in-gerritforge/)
which contains:

- The support for cloud-native events-brokers: Google's GCloud Pub/Sub and AWS Kinesis streams
- Proto-buffers for representing events for Gerrit v3.4
- Further improvements in the pull-replication plugin
- Integration of Jenkins with the new CI reboot in Gerrit v3.4

### Policies for PolyGerrit dependencies up-to-date

Gerrit Code Review code-base is mirrored on the [GerritCodeReview project in GitHub](https://github.com/gerritcodereview)
which automates the [Dependabots's security checks and warnings](https://dependabot.com/).

Ben will be also added to the list of GitHub project's owners so that the PolyGerrit Team can
receive and assess all the feedback provided by Dependabot.

### Top #3 PolyGerrit-related show-stoppers vs. GWT UI

GerritForge has performed a survey with its clients to identify the top #3 problems
that companies have indicated as show-stoppers for migrating to PolyGerrit in Gerrit v2.16
and beyond.

1. [Issue 40012178](https://issues.gerritcodereview.com/issues/40012178): Horizontal spacing usage

2. [Issue 40013256](https://issues.gerritcodereview.com/issues/40013256): Lack of CSS customisation

3. [Issue 40011499](https://issues.gerritcodereview.com/issues/40011499): Gap in browsers support

There is positive attitude for discussing those issues with Ben and the PolyGerrit Team and
find possible solutions. GerritForge has offered its development Team to cooperate with the
development and fix of the above issues, with the agreement of the rest of the community.

### Eclipse moving away from Gerrit

The Eclipse system administrator has announced the intention to move away from Gerrit.
Matthias described the current situation for at least JGit/EGit projects and the intention
to keep Gerrit as code-review system for the projects.

The discussion inside the Eclipse foundation continues, there are no actions for the ESC
at this point in time.