MediaWiki version 1.29 should be coming out on the 25th (2 days), so just making this task now.
Description
Related Objects
Event Timeline
Release date not looking good. https://lists.wikimedia.org/pipermail/wikitech-l/2017-May/088238.html
Since the release is not possible yet, I am moving this back to "Normal" until 1.29 is actually released.
FYI MediaWiki 1.29 is working (https://test1.miraheze.org/wiki/Special:Version) without any extensions enabled. The next steps are to check/add SQL files to wmgCreateWikiSQLfiles and then test the upgrade with extensions on extloadwiki (or test1wiki).
SQL changes (patches):
Flow:
/srv/mediawiki/w/extensions/Flow/db_patches/patch-add-wiki.sql
/srv/mediawiki/w/extensions/Flow/db_patches/patch-addindex_flow_ext_ref_idx_v3.sql
/srv/mediawiki/w/extensions/Flow/db_patches/patch-drop-flow_subscription.sql
/srv/mediawiki/w/extensions/Flow/db_patches/patch-dropindex-flow_ext_ref_idx_v2.sql
/srv/mediawiki/w/extensions/Flow/db_patches/patch-increase_width_wiki_fields.sql
/srv/mediawiki/w/extensions/Flow/db_patches/patch-ref_target_not_null.sql
/srv/mediawiki/w/extensions/Flow/db_patches/patch-primary-keys.sql
/srv/mediawiki/w/extensions/Flow/db_patches/patch-increase_width_wiki_fields.sql
Newsletter:
/srv/mediawiki/w/extensions/Newsletter/sql/nl_newsletters-add-unique.sql
/srv/mediawiki/w/extensions/Newsletter/sql/nl_main_page_id-drop-index.sql
/srv/mediawiki/w/extensions/Newsletter/sql/nl_newsletters.sql
PageTriage:
/srv/mediawiki/w/extensions/PageTriage/sql/PageTriageLog.sql
/srv/mediawiki/w/extensions/PageTriage/sql/PageTriageLogPatch_Drop_ptrl_comment.sql
SocialProfile
/srv/mediawiki/w/extensions/SocialProfile/UserStats/user_points_archive.sql
/srv/mediawiki/w/extensions/SocialProfile/UserStats/user_points_monthly.postgres.sql
/srv/mediawiki/w/extensions/SocialProfile/UserStats/user_points_monthly.sql
/srv/mediawiki/w/extensions/SocialProfile/UserStats/user_points_weekly.sql
WikiBase:
/srv/mediawiki/w/extensions/WikiBase/repo/sql/AddEntityPerPage.sql
/srv/mediawiki/w/extensions/WikiBase/repo/sql/AddTermsFullEntityId.sql
Re. ContentTranskation: we've never had any SQL for it. So these definitely aren't patches if they're required. Check upstream for database config please.
In the meantime, there are issues with two extensions while upgrading to 1.29: AccessControl and ArticleFeedbackV5.
ArticleFeedbackV5 could be (as we did with others in the past) disabled until we figure it out.
AccessControl is a larger problem, as it is used to protect private information, so disabling it would not be a good idea. I'm not sure what we can do about it.
Since the issues are likely upstream I have opened two tasks but in the meantime we need to decide what we'll do with AccessControl unless we figure something out
https://phabricator.wikimedia.org/T172718
https://phabricator.wikimedia.org/T172771
Even though we prefer REL branches, the only fix for ArticleFeedbackV5 seems to be switching to the master branch.
If upstream say use master, use master. Our preference isn't using RELs, its a standard of versioning we use.
Will do but AccessControl is still a blocker, and with it not working for the reasons mentioned above we can't upgrade.
I think our best option is to temporarily disable AccessControl until the upstream issue is resolved. Wikis where AccessControl is currently enabled are below. @NDKilla Since there might be private information I propose that unless they already are we make all the wikis private:
bmedwiki - Closed | No apparent use of AccessControl
claneuphoriawiki - Open | Errors with AccessControl was discussed on Phabricator; not sure they were ever resolved
extloadwiki - N/A
test1wiki - N/A
metaautonomywiki - Deleted
mindgearwiki - Closed | Cannot confirm if AccessControl is/was being used PRIVATE
ndnwiki - Deleted
westmarcheswiki - Open | Cannot confirm if AccessControl is being used PRIVATE
wimawiki - Closed | Cannot confirm if AccessControl is/was being used
wisdomwikiwiki - Closed | Requester gave me permission to disable if needed
wisdomsandboxwiki - Closed | Requester gave me permission to disable if needed
The issue with AC is they use it to segregate people. Whether a wiki is public or private is irrelevant as User A shouldn't be able to read page B under any circumstance.
Attempt to confirm usage and discuss. If there's no usage, kill it.
But the people would automatically be out, since when the wiki is made private they aren't members. Since the wikis are closed I doubt I'll get answers from those.
@John Two of the wikis in question are private. I guess I could just manually check every page and find if AccessControl is being used. In the case that it is, what should be done (assuming that the bureacurats are not active, hence why the wikis are closed and that they will not respond)?
If they're closed they're unmaintained. Fast track delete if close to deletion date otherwise remove from cw_wikis and make a calendar note for yourself,
One of them is closed, and I'm in luck, 6 months from closure is in 2 days! The other one is open, but no edits since the first of June so that one might be a problem (I'll search to make sure if it's actually being used)
There is only one page which I assume uses AC, https://westmarches.miraheze.org/wiki/Information_for_Game_Masters. It currently gives a 500 HTTP error, but I'm sure if AC is disabled that will not be the case. I think the solution is to delete that page, maybe oversight it and if the bureaucrats need it, they can request it back.
There's no greater teacher than expierence apparently.
I'll document the entire process since my role is no longer "do it" but rather "teach it".
mw2 is waiting to be deployed but mw1 is in action on 1.29.
This upgrade took 3x longer than the past ones and than I expected, no learning points though really. Maybe less wikis? Who knows.
It's done and this makes me 3/4 on MediaWiki upgrades now (3/3 on the last 3!)