Page MenuHomePhabricator

Put "shim" code for namespaces, logs, and log i18n into WikimediaMessages so we can undeploy extensions
Closed, ResolvedPublic0 Estimated Story Points

Description

Problem:

  • From time to time, we want to undeploy certain extensions from wikis, or from all of production.
  • However, doing so poses some problems:
    • Logs created by extensions will suddenly disappear, breaking the concept of on-wiki auditability;
    • Logs related to namespaces registered by extensions will disappear; and
    • Log entries created by extensions will appear as un-rendered i18n because it's no longer registered (only when removing the extension from all of production).
  • This problem makes us hesitant to remove code we want to (like UserMerge), or leave code "on" when it's off (like LiquidThreads).
  • Occasionally we make the decision to drop extensions from wikis anyway (for expediency or other reasons), leaving unfixable brokenness behind.

Proposal:

  • Create a series of shims for extensions in the WikimediaMessages extension that only register namespaces, logs, and i18n.
  • For wikis where we're removing extension Foo, enable WikimediaMessages's Foo shim in mw-config.
  • For extensions which were on all wikis and now are on none, default them on in WikimediaMessages.

Sane?

Event Timeline

Sounds sane to me; except that I think the scope might need to be extended to random other bits (beyond namespaces, log types and i18n) that we're not thinking of now but will discover when we try to undeploy an extension.

Should this be a blocker of the removal of UserMerge/CodeReview?

Should this be a blocker of the removal of UserMerge/CodeReview?

Yes.

How will translations be handled? One-off dump of translations when the shim is created? Does that need a script?

How will translations be handled? One-off dump of translations when the shim is created? Does that need a script?

I was planning on an initial one-off dump into WikimediaMessages with prefixed keys, yes (so lqt-desc would become wikimediamessages-shim-lqt-desc etc.); the "new" i18n would show up (with a different name) on translatewiki which would allow further translation. This way we support full translation as normal whilst allowing divergence if e.g. the extension adds different functionality after being undeployed, and without adding more complexity to the TWN world. Does this make sense?

It will create some duplication, but it seems acceptable to me.

greg triaged this task as Medium priority.Jul 3 2019, 10:29 PM
Jdforrester-WMF lowered the priority of this task from Medium to Low.Feb 24 2020, 5:38 PM

Removing task assignee due to inactivity, as this open task has been assigned for more than two years (see emails sent to assignee on May26 and Jun17, and T270544). Please assign this task to yourself again if you still realistically [plan to] work on this task - it would be very welcome!

(See https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup for tips how to best manage your individual work in Phabricator.)

Change 752150 had a related patch set uploaded (by Majavah; author: Majavah):

[mediawiki/extensions/WikimediaMessages@master] Add placeholders for UserMerge log entries

https://gerrit.wikimedia.org/r/752150

Change 752150 merged by jenkins-bot:

[mediawiki/extensions/WikimediaMessages@master] Add placeholders for UserMerge log entries

https://gerrit.wikimedia.org/r/752150

taavi claimed this task.