krenair@deployment-tin:/srv/mediawiki-staging$ git diff diff --git a/wmf-config/event-schemas b/wmf-config/event-schemas index 4db9d40d2..b50f4e076 160000 --- a/wmf-config/event-schemas +++ b/wmf-config/event-schemas @@ -1 +1 @@ -Subproject commit 4db9d40d28d61c53cdbca77059d9a2a6e714af89 +Subproject commit b50f4e0763f4bfa8abf1c4f3afd43cd6067652af
For the search part of this, we do reference the schemas in there at runtime to encode some logging. That schema hasn't changed in some time (year+) though, so I'm pretty sure no one on the search team would have pushed an update.
Apparently this is something a team manages and that not always the latest commit is the prefered one as per 068ed6ea355c.
That wasn't reverted because it was the wrong one, it was reverted because bumping that submodule was completely unrelated to the patch being deployed. The inclusion of a submodule bump in the prior patch was unintentional and only noticed when we went to deploy it.
If this submodule is not referenced by anything else other than mediawiki then there should be no reason to bump it in deployment-prep, I'd be for resetting it to 4db9d40d28d61c53cdbca77059d9a2a6e714af89 to match prod.
Side note: I'm pretty sure that https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/300880 was unnecessary. This submodule in mw-config is not meant to be updated whenever a change to it is applied, only when schema used by MW is updated.
Then to the question: why event-schema was bumped directly on deployment-tin? I have no clue, so if nobody requires it I'd be for cleaning it and align it to prod.