ESC meeting minutes
Change-Id: I96cfcea71d51ccac74fbf847aa23fea846c8a367
diff --git a/_posts/2021-03-09-esc-minutes.md b/_posts/2021-03-09-esc-minutes.md
new file mode 100644
index 0000000..14821bb
--- /dev/null
+++ b/_posts/2021-03-09-esc-minutes.md
@@ -0,0 +1,186 @@
+---
+title: "Gerrit ESC Meeting Minutes"
+tags: esc
+keywords: esc minutes
+permalink: 2021-03-09-esc-minutes.html
+summary: "Minutes from the ESC meeting held on Mar 9, 2021"
+hide_sidebar: true
+hide_navtoggle: true
+toc: true
+---
+
+## Engineering Steering Committee Meeting, Mar 9, 2021
+
+### Attendees
+
+Ben Rohlfs, Han-Wen Nienhuys, Luca Milanesio, Patrick Hiesel, Saša Živkov
+
+### Place/Date/Duration
+
+Online, Mar 9, 11:00 - 12:00 CET
+
+### Next meeting
+
+Apr 06, 2021 - 11:00 - 12:00 CET
+
+## Minutes
+
+### Gerrit events rewrite and GCloud pub/sub notifications
+
+ Han-Wen has proposed [Change-Id: Ia54acb37](https://gerrit-review.googlesource.com/c/gerrit/+/296326)
+ which represents the beginning of the initiative of having Gerrit
+ notes exported as events. The
+ [previous design in review posted by Alice](https://gerrit-review.googlesource.com/c/homepage/+/280925)
+ has been abandoned because largely outdated compared to the current
+ status on Gerrit master.
+
+### Patch-set comment experiment in Gerrit v3.3
+
+The [patch-set level comment](https://www.gerritcodereview.com/3.3.html#new-features)
+introduced in Gerrit v3.3 as an experiment could become an official
+features in v3.4.
+
+Luca proposed [Change-Id: I57569fb](https://gerrit-review.googlesource.com/c/gerrit/+/291225)
+for exposing the additional messages to stream events, so that CI systems can
+leverage it. Once the change is merged, both Zuul and Jenkins integrations
+would need to consume the new information.
+
+### ElasticSearch moved to SSPL
+
+ElasticSearch moved releases to SSPL starting 7.11. Google is opposed
+to SSPL software on principle. SAP also forbids it.
+
+Context [from the ESC in Feb](2021-02-02-esc-minutes.html):
+index support started with Lucene and Solr. Solr was clunky,
+so collabnet and ericsson worked to move to Elastic, but neither
+deployed. Alibaba seems to be using it.
+
+Decision made by the ESC is to freeze the version for now.
+Han-Wen has reached out Jacek and Marco and it looks like neither of them
+have interest in maintaining it.
+
+Luca will announce the decision to drop the ES support in core, asking
+for feedback on the consequences (if any?) on the current Gerrit users.
+
+### Design docs vs code guideline/process
+
+Qualcomm requested to have more clarity on when a design document is
+required vs. just submitting the proposal a working code in a Gerrit
+change for review.
+
+In the past the community was a lot smaller and Shawn was overseeing
+the whole code-base and could have given a lot of guidance without
+the need of a lot of input from other contributors.
+
+There is a general consensus though that a short-track of posting
+a change with a meaningful commit message could still be good enough
+when:
+
+- the change is small and has a limited impact on Gerrit functionality
+- introduces a clear and limited functionality
+- enables a trivial use-case without edge cases
+- the use case suggests a simple, single solution
+
+For all other cases, a design document is still the most valid
+approach to trigger the exchange of ideas around the new feature.
+
+### Status of the Gerrit CI pipeline changes
+
+The adoption of [Zuul](https://zuul-ci.org/) continues and the next
+step will be the validation of Gerrit changes. Once that is completed,
+Zuul can then move into the next steps of:
+- Supporting builds on RBE
+- Supporting Docker-container based tests
+
+The current [Jenkins-based CI pipeline](https://gerrit-ci.gerritforge.com) will
+still be needed though for all the other builds not related to incoming
+changes:
+- plugins stable builds
+- E2E tests
+- Other libraries
+
+### Spring cleaning of Gerrit REST-API
+
+The front-end team is tracking which Gerrit API are unused and is
+planning to remove them on master, which will become Gerrit v3.4:
+
+- Drop of Polymer2 cruft
+- Removal of *some* of 50 different API methods
+
+The initiative is guided by data observed on `*.googlesource.com`
+and a list of proposed dropped API will be also posted to repo-discuss.
+
+### Decommission of JSch on Gerrit master
+
+David has driven the initiative of [moving away from JSch](https://gerrit-review.googlesource.com/c/gerrit/+/269976)
+and adopting instead Mina SSH client.
+
+Han-Wen has already reviewed and provided the green light, Patrick is now
+reviewing the change and finalising the merge.
+
+### Release plan for Gerrit v3.4
+
+David has proposed the [Gerrit v3.4 release plan](https://gerrit-review.googlesource.com/c/homepage/+/298876)
+targeting a release date of May 17. The plan looks good and has been approved.
+
+There is a general agreement that we should continue to target Java 11 as a runtime,
+keeping the ability to be able to build the code from source on Java 8 as well.
+
+Saša expressed the concern that in Gerrit v3.3 some plugins (e.g. high-availability)
+may not be able to compile on Java 8 because of Java 11-only dependencies.
+Luca has fixed the issue with the high-availability plugin (global refdb with
+java8 classifier) but raised the concern that we cannot force all plugins' developers
+to respect that norm.
+
+There is a consensus that core plugins will continue to be compatible with Java 8
+at source level, with the recommendation (but not requirement) to do the same for
+the other plugins.
+
+### Gerrit v3.3 and double-release on Java 8
+
+Luca presented the data about the adoption of Java 11 on the latest versions of
+Gerrit:
+
+- Gerrit v3.3 JVM statistics: 3399 setups (up to 3rd Feb 2021)
+ * Java 11 (96.3%)
+ * other (3.6%)
+ * Java 8 (0.1%)
+- Gerrit v3.2 JVM statistics: 5915 setups (up to 3rd Feb 2021)
+ * Java 11 (57.2%)
+ * Java 8 (41.6%)
+ * other (1.2%)
+
+Saša mentioned the need for SAP to keep on having the source code to compile
+on Java 8, but not necessarily the requirement to have Java 8 distribution or
+binaries except that the referenced libraries should also to be Java 8 compatible
+or should be able to be recompiled with Java 8.
+
+The consensus is to keep the current policy of releasing only on Java 11 to keep
+the current adoption rate.
+
+### New features on EOL branches
+
+Following the [Change-Id: Ifebae17f](https://gerrit-review.googlesource.com/c/gerrit/+/298880)
+proposed by Luca, Han-Wen proposed to make the policy even more restrictive and
+ban the introduction of new features in any stable branch.
+
+That should also include 3rd party dependencies (either Google or non-Google ones) unless
+they are required to address critical and security bugs.
+
+There is a general consensus that brand-new features should be introduced only on master and,
+if needed cherry-picked on a un-maintained private fork should anyone needed on an earlier
+stable branch.
+
+### Roadmap updates
+
+- Protobuf in Gerrit events: Google won't be able to finalize this in time for v3.4.
+ Background: the introduction was mainly delayed by qcom wanting more justification
+ for this migration but also b/c we needed to prototype all field types that
+ we have to make sure they translate well.
+ Note that the protobuf events is obviated with our notification strategy.
+ Google still has an intent to move the API types (`*Info`, `*Input`) to protobuf.
+- Luca added to v3.4 the introduction of additional cloud-native events-brokers:
+ GCloud PubSub and/or AWS Kinesis.
+- Saša mentioned that it would be nice to have a redesign/rewirte of the replication plugin
+ code somewhere in the future, even though SAP is planning to switch to pull-replication
+ which would leverage Git protocol v2.
