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.

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.

svn2git failures
We cannot currently export anything other than phase3 -- investigating.
 * I *think* this is a weird edge-case bug you hit when you've got a malformed rule missing a trailing /. I *think*.

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) ... translators edit new or old messages ...
 * 4) Siebrand runs translatewiki.net's scripts to export localized messages back to files in the source tree
 * 5) * and may have to manually resolve conflicts
 * 6) * and may have to manually edit calling source code to correct formatting errors, misuse of options, bad description comments
 * 7) * 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.

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, 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.