Add ESC meeting minutes for Feb 2, 2021
Change-Id: Iaf85b5f547f5ef29fcd324a3448663eb16723a23
diff --git a/_posts/2021-02-02-esc-minutes.md b/_posts/2021-02-02-esc-minutes.md
new file mode 100644
index 0000000..2934818
--- /dev/null
+++ b/_posts/2021-02-02-esc-minutes.md
@@ -0,0 +1,139 @@
+---
+title: "Gerrit ESC Meeting Minutes"
+tags: esc
+keywords: esc minutes
+permalink: 2021-02-02-esc-minutes.html
+summary: "Minutes from the ESC meeting held on Feb 2, 2021"
+hide_sidebar: true
+hide_navtoggle: true
+toc: true
+---
+
+## Engineering Steering Committee Meeting, Feb 2, 2021
+
+### Attendees
+
+Ben Rohlfs, Han-Wen Nienhuys, Luca Milanesio, Saša Živkov
+
+### Place/Date/Duration
+
+Online, Feb 2, 11:00 - 11:45 CET
+
+### Next meeting
+
+March 02, 2021 - 11:00 - 12:00 CET
+
+## Minutes
+
+### [Selection bug](https://bugs.chromium.org/p/gerrit/issues/detail?id=11811) in Safari
+
+Frontend team at Google added a polyfill workaround. This works for
+older versions of Safari, but not for the latest version of Safari.
+This is a [browser
+bug](https://bugs.webkit.org/show_bug.cgi?id=163921).
+
+Webkit is open-source, so someone with enough time could find out what
+is going on, but Google users are not impacted, so Google can't prioritize a
+more in-depth investigation, especially given that this is a browser bug.
+
+Some deployments see larger shares of Safari users, and it's the
+default browser for mobile iOS platforms. Luca will try to reach out
+to the Safari team to get this resolved.
+
+
+### 24h grace period to let others comment
+
+Context is https://gerrit-review.googlesource.com/c/gerrit/+/294087.
+
+There used to be an unwritten rule to let other timezones look at the
+change too. For some changes (eg. fixes), it is appropriate to submit
+much more quickly. This change was not a trivial fix, though.
+
+Resolution: introduce a 24h waiting period for changes that imply a
+long-term support commitment, eg. user-visible features, or API
+extensions.
+
+
+### 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: 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.
+
+Long term technical solution: use ES as a module (ie. a non-swappable
+part of Gerrit, compiled separately). ES also slowed down our
+development, so getting rid of it may be a net positive.
+
+Resolution: we will freeze the version for now. Han-Wen will reach out
+to Jacek and Marco to see if they have interest in maintaining it.
+
+### DoS fix for HTTP sessions.
+
+Advance notice by large deployments was well received. Upgrade went smoothly.
+
+Got requests to document of our advance notice process (OpenStack).
+Luca will followup.
+
+Wikimedia builds from source, and wants to see the patch. We could
+create `refs/heads/security/*` in main gerrit repo, but risky: it's
+easy to upload to the wrong branch, so we'll keep using the separate
+repository.
+
+Resolution: find a way to provide select individuals view permission
+on our security fixes repo.
+
+### Event rewrite at Google
+
+Started, but we had no plan for integration into upstream, so taking
+internally for now.
+
+The rough plan is: provide diff between NoteDb SHA1s as protocol
+buffer, eg. by comparing two ChangeNoteStateProto proto. Internally,
+we will ship this to our internal pubsub systems.
+
+Marcin is anxious to jump in. Han-Wen: need a plan to decide how these
+diffs are generated in gerrit upstream, and then hook them up to the
+event machinery.
+
+Han-Wen will publish a sanitized version of our internal design doc.
+
+### Inter-plugin communication?
+
+First attempt in
+https://gerrit-review.googlesource.com/c/gerrit/+/54428, but abandoned
+because the scripting plugin doesn't fit.
+
+This is a feature with potential future support implications. For
+example, if we document that loading other plugins by reflection
+works, we promise to not break it.
+
+We don't want to repeat Jenkins' mistake, where every plugin can call
+into everything creating a maintenance nightmare.
+
+Do we want a designdoc? Consensus: yes. Topics to consider:
+
+* should plugins be testable?
+* what happens to a caller if a dependency provider is unloaded?
+* does verification (eg. type checking) happen compile time or runtime?
+* which parts of a plugin are available to callers?
+
+Currently there are already methods that plugins can use to communicate:
+
+1. send events (but: very loose coupling)
+2. share a common interface loaded as libmodule.
+
+### Long reviews leading to demotivation
+
+[Recent
+change](https://gerrit-review.googlesource.com/c/plugins/replication/+/292364)
+took a lot of roundtrips; stressful experience for the uploader and reviewer.
+
+Should we codify boy scout rules ("change should do 1 thing",
+"leave code better than it was before", "reviews should enlighten")?
+
+Consensus: the rules in abstract seem obvious, but subjective when
+applied. This is a people problem, so have to escalate earlier to CMs.
+
