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?
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Declined | None | T76896 Wiki Release Team First Quarter 2015 Quarterly Review | |||
| Resolved | Qgil | T76672 Wiki Release Team December Goals | |||
| Resolved | Qgil | T782 Wiki Release Team November 2014 Goals | |||
| Resolved | • demon | T529 Automate patch application for tests for QA part of make_release | |||
| Resolved | Mglaser | T537 Wiki Release Team October 2014 goals | |||
| Duplicate | MarkAHershberger | T530 Document QA requirements of MediaWiki releases | |||
| Resolved | MarkAHershberger | T492 Document the QA process for MediaWiki releases | |||
| Declined | MarkAHershberger | T536 Take DumpHTML as a use case of 3rd party extension that MediaWiki maintainers cannot ignore |
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.
The few qa tests are listed here: https://www.mediawiki.org/wiki/Release_checklist#release-qa