Change Details

We currently use Gerrit 3.4.4. This task is to upgrade to 3.5.x series. Release notes https://www.gerritcodereview.com/3.5.html Some sites experienced an increase in heap usage / GC cost. Mentioned by Sven on the repo-discuss list. It is apparently due to some tracing added to the change queries. Seems that can be worked around by setting `tracing.performanceLogging` to `false` GerritHub.io incident report: https://docs.google.com/document/d/1BcDhsWZfxwtujwyJwDAkLxMDvf1pAnS_I0pwJOnNSms/edit#heading=h.z4mrbzle14w0 It may or may not be a problem. We use 20G on average out of 32G. Release highlights ============== The few @hashar has noticed: **Case-insensitive usernames** Users can login with mixed case usernames without the risk to create duplicate accounts. The change affects the following external ids: * `gerrit` (LDAP) * `username` (login, authenticated REST and git endpoints) For a new Gerrit setup, usernames are case insensitive by default, while for existing installations the Gerrit admin can switch the functionality on/off using the [[ https://gerrit-documentation.storage.googleapis.com/Documentation/3.5.0/config-gerrit.html#auth.userNameCaseInsensitive | auth.userNameCaseInsensitive ]] setting in `gerrit.config`. NOTE: In the All-Users.git repository, the SHA-1 sum of the account is computed preserving the case of the external ID. See the full details in the [[ https://gerrit-documentation.storage.googleapis.com/Documentation/3.5.0/config-accounts.html#external-ids | Gerrit config accounts documentation ]]. Existing accounts can be migrated to the new SHA-1 sum using the [[ https://gerrit-documentation.storage.googleapis.com/Documentation/3.5.0/pgm-ChangeExternalIdCaseSensitivity.html | offline ]] or [[ https://gerrit-documentation.storage.googleapis.com/Documentation/3.5.0/externalid-case-insensitivity.html#online-migration | online ]] migration tool. **It defaults to `false` for existing installation so that should be a noop for us. We will probably to do the migration once we understand the implications**. **Request cancellation and execution deadlines** *Limit the maximal execution time for requests on the server side via [[ https://gerrit-documentation.storage.googleapis.com/Documentation/3.5.0/config-gerrit.html#deadline.id | deadline config ]]* **Performance improvements on the change screen** A new [[ https://gerrit-documentation.storage.googleapis.com/Documentation/3.5.0/config-gerrit.html#cache_names | approvals cache ]]. The new [[ https://gerrit-documentation.storage.googleapis.com/Documentation/3.5.0/config-gerrit.html#change.conflictsPredicateEnabled | change.conflictsPredicateEnabled ]] setting in `gerrit.config` disables the computation of the conflicts section avoiding a computation of complexity of O(nˆ2), where n is the number of open changes for the project the change belongs to. When set to false the GUI will leave the conflict changes section on change screen empty. **Default is `true` so we will keep the conflicting changes listed** Important notes ============ **Support for Java 8 dropped** *We run Gerrit under Java 11 since T268225* **Schema and index changes** Schema and index changes This release doesn’t contain schema changes. The changes index version has been increased to version 71. By default the index is automatically rebuilt upon the Gerrit startup after the upgrade. To run offline reindexing of the changes (optional when upgrading from v3.3.x or later): java -jar gerrit.war reindex --index changes -d site_path copy-approvals =========== From 3.5.2: The execution of the `copy-approvals` SSH command (**online**) or the `java -jar gerrit.war copy-approval` site command (**offline**) may take a long time to complete due to the full scanning of all projects.

We currently use Gerrit 3.4.4. This task is to upgrade to 3.5.x series. Release notes https://www.gerritcodereview.com/3.5.html Some sites experienced an increase in heap usage / GC cost. Mentioned by Sven on the repo-discuss list. It is apparently due to some tracing added to the change queries. Seems that can be worked around by setting `tracing.performanceLogging` to `false` GerritHub.io incident report: https://docs.google.com/document/d/1BcDhsWZfxwtujwyJwDAkLxMDvf1pAnS_I0pwJOnNSms/edit#heading=h.z4mrbzle14w0 It may or may not be a problem. We use 20G on average out of 32G. Release highlights ============== The few @hashar has noticed: **Case-insensitive usernames** Users can login with mixed case usernames without the risk to create duplicate accounts. The change affects the following external ids: * `gerrit` (LDAP) * `username` (login, authenticated REST and git endpoints) For a new Gerrit setup, usernames are case insensitive by default, while for existing installations the Gerrit admin can switch the functionality on/off using the [[ https://gerrit-documentation.storage.googleapis.com/Documentation/3.5.0/config-gerrit.html#auth.userNameCaseInsensitive | auth.userNameCaseInsensitive ]] setting in `gerrit.config`. NOTE: In the All-Users.git repository, the SHA-1 sum of the account is computed preserving the case of the external ID. See the full details in the [[ https://gerrit-documentation.storage.googleapis.com/Documentation/3.5.0/config-accounts.html#external-ids | Gerrit config accounts documentation ]]. Existing accounts can be migrated to the new SHA-1 sum using the [[ https://gerrit-documentation.storage.googleapis.com/Documentation/3.5.0/pgm-ChangeExternalIdCaseSensitivity.html | offline ]] or [[ https://gerrit-documentation.storage.googleapis.com/Documentation/3.5.0/externalid-case-insensitivity.html#online-migration | online ]] migration tool. **It defaults to `false` for existing installation so that should be a noop for us. We will probably to do the migration once we understand the implications**. **Request cancellation and execution deadlines** *Limit the maximal execution time for requests on the server side via [[ https://gerrit-documentation.storage.googleapis.com/Documentation/3.5.0/config-gerrit.html#deadline.id | deadline config ]]* **Performance improvements on the change screen** A new [[ https://gerrit-documentation.storage.googleapis.com/Documentation/3.5.0/config-gerrit.html#cache_names | approvals cache ]]. The new [[ https://gerrit-documentation.storage.googleapis.com/Documentation/3.5.0/config-gerrit.html#change.conflictsPredicateEnabled | change.conflictsPredicateEnabled ]] setting in `gerrit.config` disables the computation of the conflicts section avoiding a computation of complexity of O(nˆ2), where n is the number of open changes for the project the change belongs to. When set to false the GUI will leave the conflict changes section on change screen empty. **Default is `true` so we will keep the conflicting changes listed** Important notes ============ **Support for Java 8 dropped** *We run Gerrit under Java 11 since T268225* **Schema and index changes** Schema and index changes This release doesn’t contain schema changes. The changes index version has been increased to version 71. By default the index is automatically rebuilt upon the Gerrit startup after the upgrade. To run offline reindexing of the changes (optional when upgrading from v3.3.x or later): java -jar gerrit.war reindex --index changes -d site_path copy-approvals =========== From 3.5.2: The execution of the `copy-approvals` SSH command (**online**) or the `java -jar gerrit.war copy-approval` site command (**offline**) may take a long time to complete due to the full scanning of all projects. *This can be done after the 3.5 upgrade but must be done before the 3.6 one*

We currently use Gerrit 3.4.4. This task is to upgrade to 3.5.x series. Release notes https://www.gerritcodereview.com/3.5.html Some sites experienced an increase in heap usage / GC cost. Mentioned by Sven on the repo-discuss list. It is apparently due to some tracing added to the change queries. Seems that can be worked around by setting `tracing.performanceLogging` to `false` GerritHub.io incident report: https://docs.google.com/document/d/1BcDhsWZfxwtujwyJwDAkLxMDvf1pAnS_I0pwJOnNSms/edit#heading=h.z4mrbzle14w0 It may or may not be a problem. We use 20G on average out of 32G. Release highlights ============== The few @hashar has noticed: **Case-insensitive usernames** Users can login with mixed case usernames without the risk to create duplicate accounts. The change affects the following external ids: * `gerrit` (LDAP) * `username` (login, authenticated REST and git endpoints) For a new Gerrit setup, usernames are case insensitive by default, while for existing installations the Gerrit admin can switch the functionality on/off using the [[ https://gerrit-documentation.storage.googleapis.com/Documentation/3.5.0/config-gerrit.html#auth.userNameCaseInsensitive | auth.userNameCaseInsensitive ]] setting in `gerrit.config`. NOTE: In the All-Users.git repository, the SHA-1 sum of the account is computed preserving the case of the external ID. See the full details in the [[ https://gerrit-documentation.storage.googleapis.com/Documentation/3.5.0/config-accounts.html#external-ids | Gerrit config accounts documentation ]]. Existing accounts can be migrated to the new SHA-1 sum using the [[ https://gerrit-documentation.storage.googleapis.com/Documentation/3.5.0/pgm-ChangeExternalIdCaseSensitivity.html | offline ]] or [[ https://gerrit-documentation.storage.googleapis.com/Documentation/3.5.0/externalid-case-insensitivity.html#online-migration | online ]] migration tool. **It defaults to `false` for existing installation so that should be a noop for us. We will probably to do the migration once we understand the implications**. **Request cancellation and execution deadlines** *Limit the maximal execution time for requests on the server side via [[ https://gerrit-documentation.storage.googleapis.com/Documentation/3.5.0/config-gerrit.html#deadline.id | deadline config ]]* **Performance improvements on the change screen** A new [[ https://gerrit-documentation.storage.googleapis.com/Documentation/3.5.0/config-gerrit.html#cache_names | approvals cache ]]. The new [[ https://gerrit-documentation.storage.googleapis.com/Documentation/3.5.0/config-gerrit.html#change.conflictsPredicateEnabled | change.conflictsPredicateEnabled ]] setting in `gerrit.config` disables the computation of the conflicts section avoiding a computation of complexity of O(nˆ2), where n is the number of open changes for the project the change belongs to. When set to false the GUI will leave the conflict changes section on change screen empty. **Default is `true` so we will keep the conflicting changes listed** Important notes ============ **Support for Java 8 dropped** *We run Gerrit under Java 11 since T268225* **Schema and index changes** Schema and index changes This release doesn’t contain schema changes. The changes index version has been increased to version 71. By default the index is automatically rebuilt upon the Gerrit startup after the upgrade. To run offline reindexing of the changes (optional when upgrading from v3.3.x or later): java -jar gerrit.war reindex --index changes -d site_path copy-approvals =========== From 3.5.2: The execution of the `copy-approvals` SSH command (**online**) or the `java -jar gerrit.war copy-approval` site command (**offline**) may take a long time to complete due to the full scanning of all projects. *This can be done after the 3.5 upgrade but must be done before the 3.6 one*