Review queue

From MediaWiki.org
Jump to: navigation, search

This page documents the steps needed to get MediaWiki extensions and other code through the review process before possibly being deployed to Wikimedia wikis. Anything that is deployed on the Wikimedia cluster needs to be reviewed for security and scalability issues.

Writing an extension for deployment can be a time-consuming project; any interested party is encouraged to start the process long before any deadline.

To see all extensions awaiting review, the "Task Graph" list in T33235 links to all yet unreviewed/in-progress extensions.

Once an extension has made it through reviews, then the extension can be scheduled for deployment by the Wikimedia Foundation Release Manager.

Checklist/Process[edit]

General prerequisites and expectations[edit]

Once above steps are done, consider getting community support for your idea:

  • Community support can be shown by having an active discussion on the need of the extension on a wiki and documenting the responses. If there is no active community support, support can be built through discussions and proposals.
  • Post your idea to the wikitech-l mailing list to get feedback from experienced developers and Wikimedians. People may point you to another extension that is already in use whose functionality duplicates what you want, or could be easily extended to do what you want. In that case, you should use Git to work on the extension that is already in use.
  • Communicate your ideas/plans to affected wikis to garner both support and suggestions/feedback.

If you have followed the advice above and the feedback given by early reviewers closely, you probably won't have too much of a problem with the next steps.

Preparing for deployment[edit]

  1. The production deployment tracking task:
    • Create a task in Phabricator to get an extension into the review queue. This task should only concern deployment itself. Any issues which block deployment should be separate subtasks (listed under "Task Graph") that block this parent task.
    • After creating that task, click "Edit Related Tasks… > Edit Parent Tasks" and add task number T33235.
    • Your deployment tracking bug should point to on-wiki community consensus (and/or community support/desire) for having the extension installed on a particular wiki, if applicable.
  2. Request and incorporate feedback the needed reviews:
    1. A security review: Open a security review task and mark it as a subtask of the main deployment task
    2. A product review, if applicable
    3. A design review, if applicable.
    4. If you have reasons to think that a database review is needed, create a request in Phabricator.
    5. Any serious issues identified in these reviews must be addressed before deploying your code.
  3. After the security review, request deployment to the Beta Cluster (this can aid the other reviews). See #Deploy to beta cluster on Labs below for more information.
  4. Make sure the extension is automatically branched.
  5. Request a date/time for deployment in the deployment tracking task to get it added to the deployment calendar.
    • "You" (the person or persons driving/requesting this) will need to be online (on IRC in #wikimedia-relengconnect) and available during the deployment to respond to any issues that might arise.

Compatibility with other deployed extensions[edit]

As written above, your extension must be compatible with all extensions deployed on the Wikimedia cluster. Specific issues follow.

Renameuser and UserMerge
If your extension has a database table that stores usernames, it needs to respond to the RenameUserSQL hook to add its tables. If your extension is storing user IDs or usernames, it needs to respond to one or both of the UserMergeAccountDeleteTablesExtension:UserMerge/UserMergeAccountDeleteTables, and UserMergeAccountFieldsExtension:UserMerge/UserMergeAccountFields hooks to update its tables accordingly. See hooks.txt.
Flow
If your extension makes edits to pages, you need to consider whether it should do this on Flow boards and Flow topics, and handle them specially. For example, the MassMessage extension can post a message on a Flow-enabled user talk page.

Deploy to beta cluster on Labs[edit]

Before enabling a new extension in production, it can be tested on the beta cluster. To do this:

  1. Add the new extension to the mediawiki/extensions repo. Thereafter the repository will be updated automatically as your extension changes. For example, to add a new extension called RevisionSlider: git submodule add https://gerrit.wikimedia.org/r/p/mediawiki/extensions/RevisionSlider.git
  2. Require and configure the new extension. The beta cluster uses the same wmf-config directory in the operations/mediawiki-config repository as production, but in addition the beta cluster machines load InitialiseSettings-labs.php, CommonSettings-labs.php, and extension-list-labs files so you can have settings that only apply to Labs. Read more about these config files). When testing on Labs before production, these can override wgUseMyExtension, setting it to true on one or more beta cluster wikis. (Once your extension is in use in the production wiki(s) corresponding to beta labs, you can probably remove the -labs.php overrides.)

It is possible to deploy extensions that do not exist in production to the beta cluster. However, the beta cluster runs code only from the master branch in Git. You should merge code into the master branch early and often in order to exercise that code as fully as possible on the beta cluster before it goes out to the general public. If you have specific questions about using the beta cluster, you can e-mail the Quality Assurance mailing list or ask in #wikimedia-relengconnect on IRC.

See also[edit]

Roan Kattouw's presentation on security.