Page MenuHomePhabricator

Document the QA process for MediaWiki releases
Closed, ResolvedPublic


MediaWiki 1.23.4 has created some problems to some users upgrading from 1.23.3. Without having investigated these problems deeply, in principle they look relatively simple, and the kind of problems a good QA process would have detected.

Are the QA requirements of MediaWiki releases documented?

Event Timeline

Qgil raised the priority of this task from to Needs Triage.
Qgil updated the task description. (Show Details)
Qgil added a project: Wiki-Release-Team.
Qgil changed Security from none to None.
Qgil added a subscriber: Qgil.
Palexis triaged this task as High priority.
Palexis added subscribers: MarkAHershberger, Palexis.

I'm not sure whether the T536 proposal blocks this task or vice versa. I just wanted to mark their mutual relationship.

What I mean is that DumpHTML could be a practical example to define and benchmark the MediaWiki release QA process. When MediaWiki maintainers make a change that happens to break something in a 3rd party extension not used by Wikimedia, first it goes to Wikimedia servers (therefore not affecting directly the extension), but at that point the breakage could be technically found and acted upon. The next MediaWiki release will affect that extension, so the QA process should have a checkpoint to prevent this problem, or at least communicate it to the extension maintainers and in the release notes.