Further improve Gerrit 3.10, plugins.loadPriority description
Change-Id: I3ab23a653ebd72c3b29fb724b0cc87322ca451cf
diff --git a/pages/site/releases/3.10.md b/pages/site/releases/3.10.md
index d73e8b4..6275983 100644
--- a/pages/site/releases/3.10.md
+++ b/pages/site/releases/3.10.md
@@ -16,7 +16,7 @@
Java 11 is EOL since September 2023 and Gerrit already supports Java 17.
Support for building Gerrit with Java 11 has been dropped and the default
-minimum version set to Java 17 ([Change 423318](https://gerrit-review.googlesource.com/423318)).
+minimum version set to Java 17.
### Rebase merge commits
@@ -144,14 +144,21 @@
It's now possible to update the author and the committer identities directly in
the UI.
-### Change plugin load order using `plugins.loadPriority`
+### Allow specifying plugins load ordering using `plugins.loadPriority`
-In some complex deployments of Gerrit, the order of plugins' load during
-the startup time matters.
+Currently there is no way of specifying an order in which plugins should be
+loaded, other than alphabetical. However, in some complex Gerrit deployments,
+the order in which plugins are enabled during startup matters.
-[Change 424019](https://gerrit-review.googlesource.com/424019) introduces
-`plugins.loadPriority` option of `gerrit.config` to influence the
-order of loading plugins during the startup.
+I.e. In a multi-site setup, if whichever flavour of events-broker implementation
+is loaded before pull-replication, then some events could effectively go lost,
+as pull-replication won't be ready to consume them.
+
+By using `plugins.loadPriority` we can now define the order in which plugins
+should be loaded, ensuring that no events are lost.
+
+> **Note**: If manually enabling/disabling plugins at runtime, the order is no
+> longer guaranteed.
## Important Notes
* [Change 394841](https://gerrit-review.googlesource.com/394841):
