David Pursehouse, Alice Kober-Sotzek, Patrick Hiesel, Ben Rohlfs
Online, August 6, 12:30 - 13:30 CEST
The next meeting will be held on August 20, 12:30 CEST.
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.
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.
We had a rather long discussion about the design and decided to reject it. Alice will post a detailed response on that change.
Patrick's alternative solution was submitted. We will come back to this in the next meeting after data has been gathered.
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.
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.
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.