Talk:Git/Conversion/issues

Topics for Chad's email to wikitech-l this week
Topics Chad will need to address:


 * how are we gonna handle the translators' work?
 * Chad has talked with Siebrand about this very roughly. We'd like to automate this process as much as possible--it currently takes about 20mins/day for Raymond to do and that's a huge timesink.
 * what about gerrit? when will it be not a UX nightmare?
 * File bugs upstream! We're looking at how open their community is to non-Google contribution. The backend is *really solid* and if we've got annoying UI bugs hopefully we can push on getting them fixed.
 * So, you're saying that we are going to simply use gerrit as-is, even though its usability sucks? Why not make it bearable before we switch and we have to use it?  And why not use Phabricator?
 * I'm not convinced it's a "usability nightmare." It's just a matter of learning a new tool that we're unfamiliar with. Yes there are some rough edges, but it's largely good. Plus, Gerrit it 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 w.r.t. gerrit-isms when committing. I wish someone had brought up Phabricator about 6-9 months ago, rather than in the last ~month when we've already started making plans with gerrit. Other than the UI being sub-par, I've yet to see any substantive arguments against using gerrit--it supports the commit model we want, has built-in LDAP support already, and has a robust permissions system that applies per-project.
 * who will be able to commit to what?
 * Everyone will be able to push to everything.
 * OK, so, who will be able to PULL for what?
 * For core, look at "who will have the ability to do code review?" For extensions, we will follow that practice, and for any given extension, we will honor the wishes of the person/s listed as the main author on the extension's mediawiki.org page.
 * who will have the ability to do code review?
 * Ops, insofar as they have code review rights globally. In practice I doubt they'll review much MediaWiki stuff
 * "Code Review group" - This would be based on our current crop of code reviewers. Remember that gerrit requires a +2 on CR to merge, so we can give +1 rights to all committers, sort of like "signoffs" in our current setup.
 * "Current crop of code reviewers" -- so, everyone who currently has core commit access? An alternative: start with the people who currently have deploy access.
 * Yeah, starting with the deployment group would be good. Especially for the "WMF" branch (see below)
 * Extension owners will be able to +2 their extensions (plus the above CR group and ops), unless they choose the "I don't want review, just let me push" workflow (which can be customized per-extension). We could define groups to make this easier for batches of extensions (eg: SMW developers?)
 * how do I get training on using the new tools?
 * Guides will need updating -- could plan a workshop at WM2012 to hit a wide audience + be filmed?
 * Wikimania is in July. Aren't we talking about moving MediaWiki core + extensions at least four months before that?
 * Well the guides will be updated well before Wikimania. But I don't see any other time to do training until then unless someone else is volunteering.
 * Who is going to update the code review guides, and when?
 * what deadlines do I need to know?
 * I run a project that's currently hosted at svn.wikimedia.org -- how do I convert to git?
 * Ask Chad and he'll help you.
 * WMF branch strategy
 * Maintain a "WMF" branch of mediawiki/core.git. Use submodules for deployed extensions, can pull from master as regularly as we want for deployments.