Git/Conversion/issues
This page is obsolete. It is being retained for archival purposes. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on the information here being up-to-date. |
Please do not add any issue on this page, instead use the issue tracker at https://phabricator.wikimedia.org/ and open your bug against the Gerrit project |
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.
Localization
editSee mailarchive:wikitech-l/2012-March/059348.html
There are a few remaining issues:
- automatic merging of translation commits [BLOCKER]
- not spamming your inbox with translation update commits
The special Wikimedia Foundation branch & submodules
editWe 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
editWe'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
editWe'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.
How-to for users
edit- Download from Git
- Fix all the links and stuff around
- How to update core and extensions (formerly svn up)
- Especially when they're not all in git
- ...
Other
editOur timeline and Git/Conversion#Unscheduled_items also include some issues that need addressing.