Git/Conversion/issues

There's a lot of folks wanting to migrate MediaWiki to git distributed source control, but there are a few issues still to sort out. This page is meant to lay out a few of those and make sure we know what needs to be done; please consider this a discussion aid, not a formal todo list.

What's the workflow for drive-by pushes?
Right now, in order to submit a patch, Git/Workflow suggests that you get a Gerrit account before you clone. How do we enable much more casual or one-off committers? I want experienced developers to be able to randomly fork and request pulls without having to get an account. If the answer is "for now, link to your fork in a Bugzilla comment and mark it 'patch' 'need-review'," that's adequate (because we let people get Bugzilla accounts without waiting for a gatekeeper), but if there's a better way I'd like to know it so we can update docs. Sumana Harihareswara, Wikimedia Foundation Volunteer Development Coordinator (talk) 15:07, 26 February 2012 (UTC)


 * Workaround: Make it clear how to clone anonymously, submit a diff into BZ as a patch/attachment.Sumana Harihareswara, Wikimedia Foundation Volunteer Development Coordinator (talk) 16:29, 9 March 2012 (UTC)

Project list opaque
[Non blocking but annoying] lists all the projects in gerrit, but it's hard to find in the UI if you're logged in, and isn't shown anywhere if you're anonymous (even though you can read it!). Maybe have something that scrapes this data at some interval and makes it available to labsconsole & mw.org.

Localization
First, a brief overview of the localization process today:


 * 1) code is checked into SVN which adds or changes localized messages
 * 2) Translatewiki.net's automated updates import the new messages into the wiki for editing
 * 3) * translatewiki.net:/home/betawiki/update-mediawiki-ext
 * 4) ... translators edit new or old messages ...
 * 5) Siebrand runs translatewiki.net's scripts to export localized messages back to files in the source tree
 * 6) * translatewiki.net:/home/betawiki/bpmw
 * 7) Apply changes to local copy
 * 8) * and may have to manually resolve conflicts
 * 9) * and may have to manually edit calling source code to correct formatting errors, misuse of options, bad description comments
 * 10) * and then commits it to upstream SVN

This process isn't inherently unfriendly to git -- it works pretty much the same way for l10n updates for StatusNet -- however the issue of may complicate this.

StatusNet's git repository today stores all plugins in the same repo as core, which behaves about the same as MediaWiki's SVN situation.

If instead we put each extension in a separate repository, then the process will need many more checkouts and more commits to run a full update on everything. Not impossible, but would at least require changes to Translatewiki.net's processes to make it manageable.

The special Wikimedia Foundation branch & submodules
We will have a branch of the core software that never stays too far behind master, and extensions we deploy can be added as submodules within that branch. You can differ submodules across branches. So, part of deployment process is going to be: update rev in that.


 * if you are deploying part of core, grab from master
 * if it's an extension, grab the reference the submodule is pointing to

This reduces time to deploy, but we have a branch apart from master that we can be picky about. and we have a gated version of extensions. (You might not be able to nest submodules.)

We need some tools to work with this. Aaron will see what will be involved re changing procedure on fenari. Chad will add the branch and start pulling in submodules we want.

Code review workflow
We're working on the code review workflow and will use git-review and gerrit (and, in the future, possibly switch to Phabricator).

Some people have complained about gerrit's user interface. Right now we are discussing whether any of those problems are actually blockers to the migration -- please list specific issues on the dedicated gerrit bugs page and speak up if there's something that's a blocker!

Gerrit supports the commit model we want, has built-in LDAP support already, and has a robust permissions system that applies per-project. It's being used by a lot of places outside of Android, and seems to enjoy wide support. Plus, with git-review, it lowers some of the bars regarding gerrit-isms when committing.

Phabricator, while nice-looking, lacks good LDAP support, so we can't switch to it in March 2012. It is unlikely that our community can get those back-end features added and tested, to a quality comparable to gerrit's support for those features, by March. However, three months after MW core switches to git-and-gerrit, we'll have a serious tools overview and evaluate gerrit, git-review, gitweb, and all the other parts of our code management infrastructure, and revisit the gerrit decision. At that time we might find that Phabricator is a better fit, and git repos are more portable than Subversion ones are, so switching would be feasible.

Facilitating patches from Bugzilla
We'd like to make it so Bugzilla patches automatically turn into git pull requests. Rusty Burchfield is working on git-review/gerrit/Bugzilla integration (see https://github.com/GICodeWarrior/patch-tester ), and Roan Kattouw would like to also work on it. The future of such a tool depends on gerrit vs phabricator vs whatever code review tool we decide to use in the long run.

Other
Our timeline and Git/Conversion also include some issues that need addressing.