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.

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 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 and decided to reject it. Alice will post a detailed response on that change.

Redesign of external IDs

Patrick's alternative solution 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.

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’ and change 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.