Backporting fixes

Bugs are found in MediaWiki all the time. Some of these bugs are pretty high priority for the Wikimedia Foundation (eg: security-related or they break needed functionality by the Wikimedia community) and need special care to ensure all of the right users get the fix in the appropriate amount of time. There are three main classes of backports:
 * 1) Those that are security related and thus need to be disseminated as widely as possible as quickly as possible;
 * 2) Those that need to be applied to any stable or released (and supported) version of MediaWiki
 * 3) And those that need to be applied to the Wikimedia Foundation server cluster that hosts the wikis for Wikimedia-related projects.

Security-related backports

 * 1) If you find a security flaw in MediaWiki, please email security@wikimedia.org directly with details. Please give us a couple days to fix the issue and roll out new releases for third-party users before public disclosure.
 * 2) These are filed as bugs in Bugzilla, but are marked Security and thus are not public before the fix has been released.
 * 3) The issue is diagnosed and a solution is created.
 * 4) A 'hotfix' is deployed to the WMF Cluster, where all of the Wikimedia Wikis are hosted.
 * NB: The WMF Cluster is running up to two different MediaWiki versions at any time, and both versions are hotfixed at the same time; ie: to 1.22wmf1 and 1.22wmf2.
 * 1) After this hotfix is deployed a security tarball release of MediaWiki is made for all currently supported versions and made available for download.

Backports to stable/supported release
Not strictly in this order:


 * 1) A bug is found that is causing problems to users of released versions of MediaWiki.
 * 2) The bug is fixed in the development version of MediaWiki and tested there.
 * 3) Someone proposes it to be backported to the Stable/Supported versions of MediaWiki by setting the "Backport_to_Stable" flag to "?" on the bug.
 * See this bug list
 * Note: This sends the MediaWiki Release Manager an email.
 * 1) The MediaWiki Release Manager determines if the bug is important enough to backport the fix. If not the flag is set to "-" (reject).
 * This decision is based on criteria such as: number of users affected, severity of the issue, and complexity of the fix.
 * 1) The fix is applied to the Stable version of MediaWiki (ie: cherry-pick 'd) with additional tests there and approved by the release manager or anyone else with +2 rights. After the change is approved, the flag is set to "+" to clarify that all is done. See Gerrit/Advanced usage for more on how to submit the change to the stable branch.
 * The RELEASE_NOTES file should be updated for any backports. The RELEASE_NOTES file may cause problems for cherry picking in git, so the MediaWiki Release Manager may ask you to update the RELEASE_NOTES file if you are involved in the backport.
 * 1) A new tarball release of MediaWiki may be created and announced at some point.
 * There are no clear rules for this. Chris Steipp makes releases only for security reasons. The number of approved changes in the stable branch is also looked at when deciding if a new release is needed.

Backports to WMF cluster
The cluster serving WMF wikis runs pre-release 1.NNwmfXX versions of the MediaWiki software. For the avoidance of doubt, these fixes should be cherry-picks to reduce the chances of unrelated bugs being deployed.
 * 1) Make sure there is a bug registered in Bugzilla for the issue.
 * 2) On that bug, set the Backport_WMF "flag" to the "?" option.
 * Note: This sends the WMF Release Manager an email.
 * 1) The WMF Release Manager determines if the fix for this bug is worthy of being backported to the currently deployed code.
 * 2) If yes, they will set it to "+"
 * 3) If no, they will set it to "-"
 * 4) If set to "+", then the WMF Release Manager will schedule a deployment window for this fix (depending on when the bug is fixed, of course).
 * NB: Do not set the bug to "resolved" until after the fix has been deployed.
 * NB: Also, see Gerrit/Advanced usage for more on how to submit the change to the deployed branches.
 * 1) During that window, the fix will be deployed to all currently in use wmfXX branches (see the 1.22 roadmap for which versions those are).