Page MenuHomePhabricator

Take DumpHTML as a use case of 3rd party extension that MediaWiki maintainers cannot ignore
Closed, DeclinedPublic

Description

There are third party extensions that interact tightly with MediaWiki core, and suffer directly the consequences of changes in core. These extensions need

  1. better communication about these changes
  2. quick reviews to the changes their maintainers submit to core to improve compatibility

Daniel Friesen explains the case of the DumpHTML extension, as mentioned in T392#6179. Let's use this extension as an example to document this problem and agree on the best practices to solve them.

Event Timeline

Palexis created this task.Oct 1 2014, 10:59 PM
Palexis updated the task description. (Show Details)
Palexis raised the priority of this task from to Normal.
Palexis assigned this task to MarkAHershberger.
Palexis added a project: Wiki-Release-Team.
Palexis changed Security from none to None.
Palexis renamed this task from Follow and respond to Wikitech-l post by Daniel Friesen to Read and respond to Wikitech-l post by Daniel Friesen.
MarkAHershberger added a comment.EditedOct 2 2014, 2:29 AM

We could use DumpHTML to act as a sort of "canary in the coal mine" and let us know when extensions need work. We could also update it and the example extensions with some tests that the test harness run.

Palexis moved this task from Backlog to Doing on the Wiki-Release-Team board.Oct 2 2014, 2:36 AM
Qgil renamed this task from Read and respond to Wikitech-l post by Daniel Friesen to Take DumpHTML as a use case of 3rd party extension that MediaWiki maintainers cannot ignore.Oct 2 2014, 5:35 AM
Qgil updated the task description. (Show Details)

I have edited the task to make it clearer. This doesn't mean that I'm asking you to do so. Like any other task, first of all is a proposal. You will decide wether you accept it or decline it, and if you accept it, when will you work on it.

Palexis removed MarkAHershberger as the assignee of this task.Oct 21 2014, 2:44 PM

From https://gerrit.wikimedia.org/r/#/c/168207/

Extensions may add tests by directory

The UnitTestsList hook can now be used to add entire directories of
tests, à la phpunit.xml's <directory> tag. The test suite is built by
recursively scanning the directory for any files ending in "Test.php".

greg added a subscriber: greg.Feb 12 2015, 5:58 PM

We are in the process of making a Jenkins pre-merge job that runs all of the WMF deployed extensions unit tests for a commit in either MW Core or any of those other extensions (see T69216). Lobbying for another extension to be added to that group should be made on a case-by-case basis. I move to close this task as "decline" and move forward more positively.

greg writes:

I move to close this task as "decline" and move forward more positively.

I'm fine with "decline" but I would like to understand what you mean by
"move forward positively".

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 9 2015, 9:18 AM
greg closed this task as Declined.Aug 10 2015, 3:22 PM

greg writes:

I move to close this task as "decline" and move forward more positively.

I'm fine with "decline" but I would like to understand what you mean by
"move forward positively".

The phrase "use case ... MW maintainers cannot ignore" just sounds antagonistic, is all.

If an extension needs to (absolutely) be working with MW master at all times, it simply should have unit/integration tests associated with it that are voting for for a merge into core. Right now we have a job that has (many of) the WMF deployed extensions doing that so that we don't break production accidentally. We can do similarly for "MW tarball" use cases if need be.

That change/proposal should go in the CI Config project, when it is ready to be proposed.