Developer account/Subversion


 * This follows on from How to become a MediaWiki hacker.
 * The Subversion page may also be useful.

This page provides a quick overview of useful things to know when starting out with MediaWiki commit access. If there is something that you find useful, and which is not shown on this page, then please add it.

Prerequisites
Before applying for commit access, you should typically have:


 * A demonstration that your request is made in good faith. For example, someone may be employing you to work on MediaWiki, or you may be known to the Wikimedia volunteer community by way of past work.
 * Plans to contribute to MediaWiki or extensions in a substantial way.
 * Programming skills appropriate for the type of work you propose to do. Our community will help new participants, especially with MediaWiki-specific skills, but we don't have time to train programmers from scratch.
 * An account on this wiki (www.mediawiki.org) with email enabled.

Request format
Commit access requests should be sent to [mailto:commit-access-requests@wikimedia.org commit-access-requests@wikimedia.org].

Your request should contain the following information:


 * Requested user name : Commit names must be lowercase, not contain spaces, and use only ASCII characters.
 * Your www.mediawiki.org user name : You must be registered and have email features enabled to receive code review feedback.
 * What you expect to work on: Which extensions, core modules, etc.
 * A link to your SSH public key : This will be used to authenticate you when you commit changes. For security reasons, it should preferably be hosted on your personal webserver, or posted to a wiki by a user name known to us. The key should be in plain text, not embedded in HTML. ssh-keygen and PuTTYgen are examples of programs that can generate a key for you.
 * Past work on MediaWiki : Patches, extensions, bug reports, etc.
 * Past programming experience : Other open source projects, etc.

Getting started and set up

 * 1) First make your SSH public key available (if you don't have a key, create one). (Not your private key! Don't share that with anyone!)
 * On a Linux system, this will be your ~/.ssh/id_rsa.pub file. (ssh-keygen -e output better?)
 * On Windows, you need to generate a private & public key with PuTTYGen and save both files.
 * 1) *Upload this file to your personal web host, (e.g. http://yoursite.domain.org/id_rsa.pub ). Also indicate what username you would prefer. We'll assume here that your chosen username is: "myUserName".
 * 2) Before you can start, you need commit permissions from the lead developers, see above for details.
 * 3) Then when you have an account, you need to follow some steps before you can commit anything. First read Subversion to get an overview of the Subversion source control system.
 * 4) Then read Subversion/auto-props, and do exactly what it says to set up auto-props.
 * 5) Then checkout using svn+ssh:// instead of http://, or it simply won't work (you may get a 403 Forbidden unexpected return value). It's, generally speaking, a good idea to have a different checked-out copy for committing than you use for development - this makes it less likely that you'll confuse patches. To do this, use: svn checkout svn+ssh://myUserName@svn.wikimedia.org/svnroot/mediawiki/trunk/phase3 wiki
 * Note: If you are prompted for a password and your SSH key doesn't need a passphrase, this may be an indication that your account has not been set up correctly. If you're using Windows, check that Pageant is running with your private key stored.
 * 1) Create a USERINFO file.
 * 2) Have a coder link your SVN account to your wiki account, so that you receive emails when somebody comments on your commits. If you're feeling bold, you could instead ask a coder to make you a coder; you can then link your account yourself at Special:Code/MediaWiki/author/.

Guidelines for applying patches
cd maintenance php parserTests.php --quiet --quick --color=no ... and compare the failures before with the failures after, to check that there were no regressions.
 * Remember that trunk is supposed to be live code -- keeping things up to date and ready to run at all times is our biggest method of quality control. Code must work at all times, except of course when it's broken by accident.
 * Always update the RELEASE-NOTES file if you fix a bug in bugzilla, or make a non-trivial change. This also applies to any changes that are visible to the end-user and any significant architectural changes or rewrites (even if not user visible), where those changes will impact third party extensions. By convention, changes are added chronologically to the end of the RELEASE-NOTES.
 * Consider possible security implications (e.g. see this security note for extension authors).
 * Do not backport any new features to the stable trunk without prior permission. In fact, best to just leave the stable trunk alone. Leave all backporting of fixes to the release manager, and save yourself grief. Things should only be backported if they are a security fix, or are vital for the software to run. Also, new features don't go into maintenance releases of old versions.
 * Don't touch the release tags at all. Ever!
 * Try not to break things, or people may get cranky. For example, if you are changing the parser, you can run parserTests before and after to help determine if your change introduced any new breakages, like so:
 * Test all patches thoroughly before applying them to SVN HEAD.
 * Try not to make any big changes right before the tree is branched into a stable release (this currently happens once every 3 months).
 * If you're the very first person updating the RELEASE-NOTES after a stable release (i.e. at the start of the new cycle), the procedure is to move the changelog entries (e.g. the "changes since 1.7" bit) from the RELEASE-NOTES file into the HISTORY file. Once it has been moved there it can then be deleted from the RELEASE-NOTES file, and a new section started (e.g. "changes since 1.8").
 * Remember to bump the $wgStyleVersion number on any updates to any .CSS or .JS files. It is in DefaultSettings.php, if you've forgotten.
 * Try not to reuse variables, and make messages easy to grep for.
 * Try not to use boolean parameters where the meaning may be unclear later - use class constants with descriptive names instead.
 * You should try to mark any new functions or variables as private, public, or protected as appropriate.
 * If you add a new hook, you need to update docs/hooks.txt with the name of the hook, a description of what the hook does, and the parameters used by the hook. It should also be included at the bottom of the "new features" section of the RELEASE-NOTES.
 * Use the WebRequest class, rather than $_GET or $_POST.
 * Try to avoid introducing new preferences, if possible, by supplying sane defaults. Remember that new preferences should very rarely be added.
 * Please try to use MediaWikis Coding conventions where possible. Read them every so often because they might be updated.
 * MediaWiki caches parser output and revision diffs. Take into account that Wikimedia and other sites use HTTP caching (with Squid or Varnish) in front of the webserver. Try not to introduce code that makes caching difficult.
 * Before committing someone else's software to Wikimedia SVN, it is best to be discussed with them first. Ideally, invite the original to apply for commit access and wait for that request to be fulfilled.

To commit to SVN
Once you have done all the above steps, you are ready to make your first commit. You should join MediaWiki developers' IRC channel (irc.freenode.net) #mediawiki. This way you people can give you direct feedback about your commits and get to know you and you them.

To prepare a commit, run svn diff List of files you want to commit. If you don't give filenames, svn picks up all files recursively from your current directory. Review the diff once more for any unrelated changes and bugs in the code. When you are ready run svn ci Same list of files. Your default text editor will pop up and ask for a commit summary. The following tips help to make good commit summaries:
 * Say what you did and why it's a good thing or needed.
 * The first line should contain concise summary of the commit.
 * In the following lines you can go into details of what and why. For bug fixes, try to give clear instructions to reproduce the bug, so reviewers can confirm that the commit does fix the problem.
 * Reference related bugs with bug 11111 and revisions with r69906 for each bug and revision. You need to use that exact syntax so that those will become links automatically.
 * Once you have written the whole summary, read it once to catch any errors.

If you want to write the summary in steps, you can use an ordinary file and the --file for the svn ci command.

Then you should get output back like this: Sending       RELEASE-NOTES Sending       includes/User.php Transmitting file data .. Committed revision 16794. Then you can close any affected bugs (if applicable) in bugzilla, using a line like "Fixed in r16794." Then hang around on #mediawiki for at least a few minutes, so that people can find you in case you broke anything. You might also get feedback on Code review, so be sure that your user account is linked and that you allow email notifications.

Some useful resources or commands
svn diff --revision 17109:17114 svn log --revision 17109:17114 --verbose svn merge -r REVISION_NUM_YOU_WANT_TO_UNDO:REVISION_NUM_TO_REVERT_TO. svn status svn diff svn commit --message="Self-revert accidental breakage" includes/file-you-changed.php includes/another-file-you-changed.php
 * To see what changed in a particular revision number, go to http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=16789 and replace the revision number in the URL as appropriate.
 * The "svn status" command will show you any files that differ between your local version and the central version.
 * The "svn diff includes/file_you_changed.php" command will show what exactly has been changed in a certain file, relative to the last checked out version.
 * If you want to see what changed between two revisions from the command line, you can use this command:
 * You should probably subscribe to the wikitech mailing list.
 * If you want to see what's changed recently, you can use the CVS mailing list.
 * Sometimes there is a small bit of lag between commits, and getting notified via CVS email. There is no lag however with SVN, so to see what's changed recently, or even not-so-recently, you can use the "svn log" command. For example this will show all changes between the specified revision numbers, and details of which files were changed:
 * You can always ask questions on the #mediawiki IRC channel. Also if the CIA-7 (or 60, or 57, or whatever the number may be) bot is working, it will print out notifications of SVN commits to the #mediawiki channel as they happen.
 * If you commit a change, and it turns out to be completely broken, then you can revert it by doing something like this:
 * To view a specific bug in bugzilla, go to http://bugzilla.wikimedia.org/show_bug.cgi?id=1234 and replace the bug number in the URL as appropriate.
 * When closing a bug in bugzilla, include a comment with something like "Fixed in r." in it - it autolinks the revision, and it helps us to keep track of changes related to bugs.
 * When committing a change which fixes a bug, always include the bug number in the commit summary.

Commit Summaries
When commiting to the MediaWiki SVN repository, please try and post an informative commit summary.

If you are doing work towards (or to fix a bug), please use the bug 1234 syntax to link it. If this commit follows on, reverts, or is related to other commits, please reference them using the r1234 syntax.

Try and ensure that your first line of your commit summary is as informative as possible. Due to the use of Code review, this only displays the first line of the commit summary in the overview. Try to be concise in this first line, and then elaborate in further detail below.

In the case of controversial, or non obvious (why you are doing them/why this is a benefit) changes, please link to any relevant discussions (if appropriate) - Bug comments, Bugzilla bugs, mailing list posts. Else, if these are not the case, explain why you are doing this commit (an essay isn't required, but "Fix bug" isn't enough information).

Going live
Code in Subversion won't immediately be live on Wikimedia wikis like Wikipedia. This is to avoid immediate breakage of the sites and to allow for code review to take place.

When a system administrator (typically Brion Vibber or Tim Starling in this case) has reviewed code changes, they will perform a standard svn update on the production cluster. At this point, changes are live on http://test.wikipedia.org, and last-minute checking can be done to ensure nothing has been broken under Wikimedia's idiosyncratic configuration.

If everything appears okay, then changes will be synchronised to application servers. This is also known as "scapping", after the "scap" script which does this.

To find out who last modified a particular line of code
Run a command like this (using the includes/Parser.php file as an example) : svn blame includes/Parser.php | less ... and then search for the line by typing "/" + your search term (e.g. the function name). It may take about 20 seconds for the svn blame output to be generated.

This will show which revision a line was modified in, and by whom, like so:

4452     timwi     $argc = count($args); 9860 kateturner 4452     timwi     for ( $i = 0; $i < $argc-1; $i++ ) { 4904    hashar          if ( substr_count ( $args[$i],  ) != substr_count ( $args[$i],  ) ) { 4904    hashar                $args[$i] .= '|'.$args[$i+1];

... you can then look up that particular revision number using the SVN web interface, to see what the commit log message was to get an explanation of why a change was made. If necessary, you can then ask the user; there is a list of SVN committers in the SVN server with contact information.

Setting up a non-standard port
Tip: Only needed if you use a non-standard port for SSH normally, otherwise ignore this. You can force SVN to use the right port number by adding this to ~/.subversion/config : [tunnels] ssh = $SVN_SSH ssh -p 22

Branching and merging
You may wish to do ongoing experimental work in a branch, so that the development trunk remains stable until your change is ready to merge. Branches are also used for the quarterly releases, so that additional bug fix releases can be made easily.

See the Subversion/branching guide for more...