Ben Rohlfs, Han-Wen Nienhuys, Luca Milanesio, Patrick Hiesel, Saša Živkov
Online, Mar 9, 11:00 - 12:00 CET
Apr 06, 2021 - 11:00 - 12:00 CET
Han-Wen has proposed Change-Id: Ia54acb37 which represents the beginning of the initiative of having Gerrit events available over the REST API. The previous design in review posted by Alice has been abandoned because largely outdated compared to the current status on Gerrit master.
Luca and GerritForge will drive a redesign targeting Gerrit v3.5.
The patch-set level comment introduced in Gerrit v3.3 as an experiment could become an official features in v3.4.
Luca proposed Change-Id: I57569fb for exposing the additional messages to stream events, so that CI systems can leverage it. Once the change is merged, both Zuul and Jenkins integrations would need to consume the new information.
ElasticSearch moved releases to SSPL starting 7.11. Google is opposed to SSPL software on principle. SAP also forbids it.
Context from the ESC in Feb: 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.
Decision made by the ESC is to freeze the version for now. Han-Wen has reached out Jacek and Marco and it looks like neither of them have interest in maintaining it.
Luca will announce the decision to drop the ES support in core, asking for feedback on the consequences (if any?) on the current Gerrit users.
Qualcomm requested to have more clarity on when a design document is required vs. just submitting the proposal a working code in a Gerrit change for review.
In the past the community was a lot smaller and Shawn was overseeing the whole code-base and could have given a lot of guidance without the need of a lot of input from other contributors.
There is a general consensus though that a short-track of posting a change with a meaningful commit message could still be good enough when:
For all other cases, a design document is still the most valid approach to trigger the exchange of ideas around the new feature.
The adoption of Zuul continues and the next step will be the validation of Gerrit changes. Once that is completed, Zuul can then move into the next steps of:
The current Jenkins-based CI pipeline will still be needed though for all the other builds not related to incoming changes:
The front-end team is tracking which Gerrit API are unused and is planning to remove them on master, which will become Gerrit v3.4:
The initiative is guided by data observed on *.googlesource.com and a list of proposed dropped API will be also posted to repo-discuss.
David has driven the initiative of moving away from JSch and adopting instead Mina SSH client.
Han-Wen has already reviewed and provided the green light, Patrick is now reviewing the change and finalising the merge.
David has proposed the Gerrit v3.4 release plan targeting a release date of May 17. The plan looks good and has been approved.
There is a general agreement that we should continue to target Java 11 as a runtime, keeping the ability to be able to build the code from source on Java 8 as well.
Saša expressed the concern that in Gerrit v3.3 some plugins (e.g. high-availability) may not be able to compile on Java 8 because of Java 11-only dependencies. Luca has fixed the issue with the high-availability plugin (global refdb with java8 classifier) but raised the concern that we cannot force all plugins' developers to respect that norm.
There is a consensus that core plugins will continue to be compatible with Java 8 at source level, with the recommendation (but not requirement) to do the same for the other plugins.
Luca presented the data about the adoption of Java 11 on the latest versions of Gerrit:
Saša mentioned the need for SAP to keep on having the source code to compile on Java 8, but not necessarily the requirement to have Java 8 distribution or binaries except that the referenced libraries should also to be Java 8 compatible or should be able to be recompiled with Java 8.
The consensus is to keep the current policy of releasing only on Java 11 to keep the current adoption rate.
Following the Change-Id: Ifebae17f proposed by Luca, Han-Wen proposed to make the policy even more restrictive and ban the introduction of new features in any stable branch.
That should also include 3rd party dependencies (either Google or non-Google ones) unless they are required to address critical and security bugs.
There is a general consensus that brand-new features should be introduced only on master and, if needed cherry-picked on a un-maintained private fork should anyone needed on an earlier stable branch.
*Info, *Input) to protobuf.