blob: b17299202fcebefd70dee70a3991c3a432cc17fb [file] [log] [blame] [view]
Luca Milanesio31be0eb2021-01-14 19:24:30 +00001---
2title: "Gerrit ESC Meeting Minutes"
3tags: esc
4keywords: esc minutes
5permalink: 2021-01-15-esc-minutes.html
6summary: "Minutes from the ESC meeting held on January 12th"
7hide_sidebar: true
8hide_navtoggle: true
9toc: true
10---
11
12## Engineering Steering Committee Meeting, January 12, 2021
13
14### Attendees
15
16Ben Rohlfs, Han-Wen Nienhuys, Patrick Hiesel, Luca Milanesio, Saša Zivkov
17
18### Place/Date/Duration
19
20Online, January 12, 11:00 - 11:45 CET
21
22### Next meeting
23
24The next meeting will be held on February 2, 11:00 CEST.
25
26## Minutes
27
28### Gerrit long-term stable releases (LTS)
29
30Should the Gerrit project start keeping long-term support branches for one or
31more releases of Gerrit? The current [EOL policy](https://www.gerritcodereview.com/support.html#supported-versions)
32defines an 18 months (3 releases) lifetime. Gerrit v2.16, released back in
33November 2018, represents an exception and will be kept for longer to allow
34existing pre-2.16 installations to migrate to Gerrit v3.x and beyond.
35
36The proposal to an extended support cycle for some elected LTS releases has been
37unanimously rejected for the following reasons:
38
39- The LTS branch would need strong governance on what can and cannot be added. The code-base
40 could diverge from the mainstream development and eventually become a _de-facto_ fork of Gerrit.
41
42- Web-browsers may not have an LTS support policy aligned with Gerrit, causing compatibility
43 issues and additional hurdles to support browser upgrades. E.g. Firefox Enterprise Edition support
44 is limited to 1 year.
45
46- The Gerrit Community focuses on helping to migrate to more recent and modern releases, such as v3.3
47 with attention-set. Having an LTS release for 5-10 years would give further incentive
48 for companies to shelf current upgrade plans.
49
50 - Older versions of Gerrit have more issues with rough edges on the user experience, which people see
51 and use to judge the product. Having more obsolete LTS versions of
52 Gerrit around would bring even more bad PR to the product itself.
53
54### Zuul for gerrit itself
55
56The Gerrit Code Review project has started adopting [Zuul](https://zuul-ci.org/) from 2019/2020 and
57it is now used for the build of a large number of plugins on the [Gerrit Zuul CI instance](https://ci.gerritforge.com).
58
59Han-Wen proposed to extend the adoption of Zuul to the CI of Gerrit itself.
60There is consensus to proceed, assuming that Zuul has bridged the gap for supporting Docker-based
61build agents, instead of GCloud VMs. Luca will follow up with James (Zuul maintainer) to check
62the status and plan the next steps.
63
64### Status of dropping Java 8 support for Gerrit
65
66Google is planning to move to Java 11 in H2/2021, allowing to drop the support for Java 8 build
67validation on Gerrit master. The target release for dropping Java 8 is therefore Gerrit v3.5, while
68Gerrit v3.4 will continue to support Java 8 compilation.
69
70### What's cooking in GerritForge for 2021
71
72Luca shared the [GerritForges shopping list for 2021](https://gitenterprise.me/2021/01/04/2021-whats-cooking-in-gerritforge/)
73which contains:
74
75- The support for cloud-native events-brokers: Google's GCloud Pub/Sub and AWS Kinesis streams
76- Proto-buffers for representing events for Gerrit v3.4
77- Further improvements in the pull-replication plugin
78- Integration of Jenkins with the new CI reboot in Gerrit v3.4
79
80### Policies for PolyGerrit dependencies up-to-date
81
82Gerrit Code Review code-base is mirrored on the [GerritCodeReview project in GitHub](https://github.com/gerritcodereview)
83which automates the [Dependabots's security checks and warnings](https://dependabot.com/).
84
85Ben will be also added to the list of GitHub project's owners so that the PolyGerrit Team can
86receive and assess all the feedback provided by Dependabot.
87
88### Top #3 PolyGerrit-related show-stoppers vs. GWT UI
89
90GerritForge has performed a survey with its clients to identify the top #3 problems
91that companies have indicated as show-stoppers for migrating to PolyGerrit in Gerrit v2.16
92and beyond.
93
Edwin Kempind3b0ab12023-06-20 08:02:45 +0000941. [Issue 40012178](https://issues.gerritcodereview.com/issues/40012178): Horizontal spacing usage
Luca Milanesio31be0eb2021-01-14 19:24:30 +000095
Edwin Kempind3b0ab12023-06-20 08:02:45 +0000962. [Issue 40013256](https://issues.gerritcodereview.com/issues/40013256): Lack of CSS customisation
Luca Milanesio31be0eb2021-01-14 19:24:30 +000097
Edwin Kempind3b0ab12023-06-20 08:02:45 +0000983. [Issue 40011499](https://issues.gerritcodereview.com/issues/40011499): Gap in browsers support
Luca Milanesio31be0eb2021-01-14 19:24:30 +000099
100There is positive attitude for discussing those issues with Ben and the PolyGerrit Team and
101find possible solutions. GerritForge has offered its development Team to cooperate with the
102development and fix of the above issues, with the agreement of the rest of the community.
103
104### Eclipse moving away from Gerrit
105
106The Eclipse system administrator has announced the intention to move away from Gerrit.
107Matthias described the current situation for at least JGit/EGit projects and the intention
108to keep Gerrit as code-review system for the projects.
109
110The discussion inside the Eclipse foundation continues, there are no actions for the ESC
111at this point in time.