Ben Rohlfs, Han-Wen Nienhuys, Patrick Hiesel, Luca Milanesio, Saša Zivkov
Online, January 12, 11:00 - 11:45 CET
The next meeting will be held on February 2, 11:00 CEST.
Should the Gerrit project start keeping long-term support branches for one or more releases of Gerrit? The current EOL policy 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.
The Gerrit Code Review project has started adopting Zuul from 2019/2020 and it is now used for the build of a large number of plugins on the Gerrit Zuul CI instance.
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.
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.
Luca shared the GerritForge’s shopping list for 2021 which contains:
Gerrit Code Review code-base is mirrored on the GerritCodeReview project in GitHub which automates the Dependabots's security checks and warnings.
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.
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.
Issue 40012178: Horizontal spacing usage
Issue 40013256: Lack of CSS customisation
Issue 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.
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.