Minutes from the ESC meeting on 6th August
Change-Id: Ic448ca766b4503344dd16fee52e9022d8d73d5c9
diff --git a/_posts/2019-08-06-esc-minutes.md b/_posts/2019-08-06-esc-minutes.md
new file mode 100644
index 0000000..9c422ea
--- /dev/null
+++ b/_posts/2019-08-06-esc-minutes.md
@@ -0,0 +1,116 @@
+---
+title: "Gerrit ESC Meeting Minutes"
+tags: news
+keywords: news
+permalink: 2019-08-06-esc-minutes.html
+summary: "Minutes from the ESC meeting held on August 6th"
+hide_sidebar: true
+hide_navtoggle: true
+toc: true
+---
+
+## Engineering Steering Committee Meeting, August 6, 2019
+
+### Attendees
+
+David Pursehouse, Alice Kober-Sotzek, Patrick Hiesel, Ben Rohlfs
+
+### Place/Date/Duration
+
+Online, July 23, 12:30 - 13:30 CEST
+
+### Next meeting
+
+The next meeting will be held on August 20, 12:30 CEST.
+
+## Minutes
+
+* Gerrit News Page
+
+ The project news for June and July was
+ [published](https://www.gerritcodereview.com/2019-07-26-gerrit-news-jun-jul-2019.html).
+
+ Although there was not a lot of content, we decided that it's worth continuing to
+ publish such news on a bi-monthly schedule. Therefore the next edition is scheduled
+ for the end of September and will cover things that have happened in August and September.
+
+ We had a brief discussion about what kind of things should be included, i.e. whether
+ it should only be news about core development. The conclusion was that anything related
+ to the project can be included, if it is of interest.
+
+ We also discussed whether it would be interesting to include sections about new
+ developers who have joined the project, for example Google recently onboarded a few new
+ [frontend developers](https://groups.google.com/d/msg/repo-discuss/CnWrhhdttFk/SDcuaRBQCwAJ)
+ and maybe it would be nice to include that kind of information. We will look into doing
+ this if it's possible to do it in a way that's not too Google-centric.
+
+* Mentoring for the pluggable Auth Backend feature
+
+ Google has tentatively confirmed that they will provide one developer to act as
+ 'mentor' for this feature for one quarter, probably Q4 of this year. We will follow
+ up on this in the next meeting.
+
+* REST API for retrieving Git trees
+
+ We had a rather long discussion about the
+ [design](https://gerrit-review.googlesource.com/c/homepage/+/231894) and decided to
+ reject it. Alice will post a detailed response on that change.
+
+* Redesign of external IDs
+
+ Patrick's [alternative solution](https://gerrit-review.googlesource.com/c/gerrit/+/231934)
+ was submitted. We will come back to this in the next meeting after data has been
+ gathered.
+
+* Recommendation on where to store global configurations
+
+ ESC was requested to provide guidance about whether global configurations should
+ go in `gerrit.config` or `All-Projects`.
+
+ This is now being tracked in
+ [issue 11285](https://bugs.chromium.org/p/gerrit/issues/detail?id=11285).
+
+* Development workflow for frontend fixes
+
+ The typical workflow for bug fixes on the backend is to submit the change to the
+ earliest appropriate stable branch and then merge up through other stable branches
+ to master. Frontend fixes, however, are generally submitted to master and then
+ cherry-picked back to the stable branch.
+
+ We discussed whether or not we should change this to align the workflow for backend
+ and frontend fixes. There were several points raised:
+
+ - It's not always obvious for a developer whether or not a fix needs to go to a
+ stable branch. It's often easier to just send it to master. This is the case for
+ both backend and frontend changes.
+
+ - If a fix gets submitted on a stable branch first, it takes some time before it
+ reaches master through merges. This particularly affects Google because they
+ run Gerrit at master.
+
+ - Release managers usually watch out for fixes that are sent to master, and
+ either change the destination branch before they are submitted, or cherry-pick
+ them after, and then take care of the merges up through to master.
+
+ - Release managers sometimes have difficulty cherry-picking or resolving merge
+ conflicts for frontend changes because they are not as familiar with frontend
+ code as they are with backend.
+
+ We concluded that we will not enforce any change in workflow, keeping the current
+ status quo. The maintainers who are more familiar with frontend code agreed to
+ provide support in cherry-picking and merging frontend fixes.
+
+* Removal of obsolete user preferences
+
+ When GWT was replaced with PolyGerrit there were some features that got dropped,
+ and the related settings are no longer presented in the UI. However, support for
+ those settings still exists in the backend.
+
+ Changes were proposed to remove them (see topic
+ '[remove-gwt-prefs](https://gerrit-review.googlesource.com/q/topic:remove-gwt-prefs)'
+ and change [230365](https://gerrit-review.googlesource.com/c/gerrit/+/230365)) but
+ the reviews have stalled after migrations were implemented to remove the unused
+ settings from user preferences.
+
+ Patrick will follow up on those reviews and look into whether we really need to
+ remove the user preferences, or if it's OK to just remove the code.
