_posts/2019-08-06-esc-minutes.md

---
title: "Gerrit ESC Meeting Minutes"
tags: esc
keywords: esc minutes
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, August 6, 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 40011036](https://issues.gerritcodereview.com/issues/40011036).

### 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.