Page MenuHomePhabricator

Document checklist steps to undeploy / sunset a codebase on WMF servers (not: archiving)
Open, Needs TriagePublic

Description

Because T235752: Undeploy the GettingStarted extension felt bumpy and more like "individuals try to remember random places".

Tagging as Code-Stewardship-Reviews because trying to find existing docs, https://www.mediawiki.org/wiki/Sunsetting_Working_Group says it's been superseded by https://www.mediawiki.org/wiki/Code_stewardship_reviews which links to https://www.mediawiki.org/wiki/Technical_Debt_Program which hasn't seen updates since 2018.

Related:

This is different from archiving a codebase, that would be T198059: Document typical criteria used to decide whether an extension or skin should be archived (with e.g. T292654: Archive the GettingStarted extension being affected)

Event Timeline

Boldly adding tech-decision-forum in lack of better ideas.
Note: The purpose of this ticket is to capture a problem. I myself as the reporter do not plan on shepherding this to completion.

Aklapper added a subscriber: Jenlenfantwright.

I've copied some intransparent access-restricted Google Doc content into the task description, for the sake of transparency and accountability.
Anyone is very welcome and invited to help filing out that stuff by editing the task description.

@Jenlenfantwright: If anything is unclear or info needed, please elaborate in this task so things can be collaboratively sorted out. Thanks for your understanding.

@LNguyen: As you removed the tech-decision-forum without an explanation: If this is for some reason out of scope for the tech-decision-forum, could you please explain why, and/or which other body would you recommend? Release-Engineering? Thanks.

Reverting since I did not get any response unfortunately. (I neither consider actions helpful that lack an explanation what's (not) going on or why, nor intransparent or unclear processes.)

For everyone's info, currently no Code-Stewardship-Reviews are taking place as there is no clear path forward and as this is not prioritized work.
(Entirely personal opinion: I also assume lack of decision authority due to WMF not having a CTO currently. However, discussing this is off-topic for this task.)

Is there at least a draft checklist somewhere? I may have a little something to contribute.

Hrm, I can start a draft here anyway—roughly, this draft is "do the the opposite of Writing an extension for deployment".

Let me caveat by saying: there's a fuzzy front-end that has no clear process as far as I'm aware.

But when it comes time to do the actual removing, these are the steps (using @Zabe's removing CongressLookup earlier today as an example):

  1. Set your extension to default false in InitialiseSettings.php (example)
  2. Remove your extension from CommonSettings.php (example)
  3. Remove your extension from InitialiseSettings.php example)
  4. Remove your extension from extension-list to stop rebuilding l10n on deployment (example)
  5. Stop branching your extension by removing it from make-release.yaml (example)

^ I'm probably missing stuff, but it's a starting point.

That's a start. My few tips:

  1. Once it's known that an extension is not going to be deployed to more languages, or that it is likely to be undeployed in the foreseeable future, move it to the "Extensions used by Wikimedia - Legacy" group on translatewiki. Configuration file: translatewiki repository, groups/MediaWiki/WikimediaLegacyAgg.yaml.
  2. Once the extension is completely undeployed from all production Wikimedia servers, remove it from all "Extensions used by Wikimedia - *" groups on translatewiki. Configuration files: translatewiki repository, groups/MediaWiki/Wikimedia*Agg.yaml (this includes "Main", "Advanced", "Media", "Legacy", "Technical", etc.).

A bit off-topic. It seems translatewiki has a couple of extensions that are not deployed to production (https://noc.wikimedia.org/conf/extension-list) in the list of Wikimedia extensions:

Maybe I'm missing something super obvious. ULS and others are probably used but I can't find the configuration of mapping it to a git repo. Some do have a repo but use a non-standard naming (e.g. ext-di-gc)

Since it's not entirely what the scope of this is and I had some part in undeploying Graphoid (one of the few things we have undeployed in my time here) mentioning T242855 and the fact that it has a checklist at the top. Some of it is specific to Graphoid, other stuff is generic for all services (DNS/LVS/puppet code removals etc).

A bit off-topic.

Thanks, it's actually quite useful!

It seems translatewiki has a couple of extensions that are not deployed to production (https://noc.wikimedia.org/conf/extension-list) in the list of Wikimedia extensions:

Good catch, thanks!

Another excellent catch! It used to be a valid id, but it was replaced by CiteThisPage long ago.

Yes, it's invalid. I'm not sure how did it happen. I probably tried to outsmart myself at some point...

If I understand correctly, it's a part of WikimediaMessages, so this one is probably not a problem.

Maybe I'm missing something super obvious. ULS and others are probably used but I can't find the configuration of mapping it to a git repo. Some do have a repo but use a non-standard naming (e.g. ext-di-gc)

ULS is used, but under a different id. And jquery-uls is another thing, and it's related, but it's not an extension, so that id is invalid.

Change 815357 had a related patch set uploaded (by Amire80; author: Amire80):

[translatewiki@master] [Used by Wikimedia] Fix several ids

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

Change 815357 merged by jenkins-bot:

[translatewiki@master] [Used by Wikimedia] Fix several ids

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

@LNguyen: Hi, an answer would be welcome.

The Forum can not take accept any tickets without an owner to take them through the process. The Forum does not have the authority to assign the ticket to any person or team.

Tech debt can't be removed because the process to remove tech debt doesn't have an owner? I think we have come full circle here.

Tech debt can't be removed because the process to remove tech debt doesn't have an owner? I think we have come full circle here.

yes, We need someone to take ownership of this if we want to take it through TDF.