== Gerrit ==
For the time being, we're sticking with gerrit for ops, MediaWiki core, and extensions: * it works for what we need * we have existing deployment workflows built on it * it's being actively developed, and various improvements are coming in
That said there are known negatives; the Java+Google Web Toolkit front-end is intimidating to people who might want to help improve the UI; even Gerrit devs don't love it. :)
Improvements to the UI and to the git-review CLI tool are welcome...
The good news for those who aren't so fond of Gerrit is that we do have some nice alternatives on the horizon, which we can start working with and improve... we'll be re-evaluating things across the board for core & extensions next year. (Ops can keep Gerrit forever if they like it, that's not my concern. ;)
== Phabricator ==
We've been pretty impressed with Phabricator and I encourage continued experimentation with it. At present it's not capable of fully taking on all our stuff -- actual repository hosting isn't finished, and I get the impression there's some UI work needed for some workflows, eg large numbers of repos (all our extensions).
Being PHP-based, it should be easier for our engineers and volunteers to jump in and modify or contribute back on Phabricator; this is something that shouldn't be underestimated. Phabricator devs seem very open to talking about improvements, and that makes me happy.
Note that projects hosted separately on GitHub can make use of Phabricator in parallel with GitHub's own pull request review system -- the test instance at https://phabricator.wmflabs.org/ includes the Wiki Loves Monuments mobile app and I plan to do more testing with it myself.
We may also be able to devise a Gerrit+Phabricator hybrid setup using the gerrit repository hosting, but that'll be something we'll have to experiment with in the future.
== Github strategy ==
I very strongly recommend having official mirrors on github that can be easily forked for experimentation. I understand this is currently waiting on the Gerrit 2.5 update, which makes things easier for the mirroring setup -- that should be ready in a month or so, unless Chad can figure out how make it work on 2.4 sooner.
Even if we don't have an automated way of accepting pull requests, a pull request is easier to work with than a patch posted to Bugzilla -- you can do the entire pull/test workflow within git, then squash (if necessary) and send up to gerrit for final review.
Note also that git-review should be able to push up to Gerrit even if you cloned from a GitHub mirror -- so a mirror may also relieve some stress on the main Gerrit server for large clones etc.
As a potential primary repository, Github is pretty good but loses on a couple fronts: * not open source -> limited in what we can customize * third-party hosting -> potential availability and customization issues ** their "GitHub enterprise" self-hosted service is not inconceivable, but still isn't open source and it's unclear what we could modify etc
Note that we are still using GitHub for projects like the Wikimedia mobile applications, which mostly predate the gerrit switch for MW core: * https://github.com/wikimedia/WikipediaMobile * https://github.com/wikimedia/WLMMobile
as well as for patched forks of other projects using GitHub, such as Apache Cordova (PhoneGap) which hosts on Apache git servers but takes a lot of contributions through forks on their GitHub mirror.
Having an official GitHub presence just makes sense.
-- brion vibber (bvibber @ wikimedia.org / brion @ pobox.com)
The good news for those who aren't so fond of Gerrit is that we do have some nice alternatives on the horizon, which we can start working with and improve... we'll be re-evaluating things across the board for core & extensions next year. (Ops can keep Gerrit forever if they like it, that's not my concern. ;)
If we switch away from Gerrit on the dev side, then we should also do so on the ops side. Having two separate workflows really sucks, and devs and ops will have to deal with it, since puppet isn't just used by ops.
Ops' requirements should be hard requirements for any solution that's chosen, if we ever switch away from Gerrit.
- Ryan
That said there are known negatives; the Java+Google Web Toolkit >front-end
is intimidating to people who might want to help improve >the UI; even Gerrit devs don't love it. :)
Improvements to the UI and to the git-review CLI tool are welcome...
Intimidating to PHP+JS only devs - but Java+Google Web Toolkit is this systems second iteration for Gerrit. I think that it would be possible to add all the changes we need into Gerrit, I personally feel more comfortable hacking Gerrit which has an upstream and a community than our previous code review plug-in which had none. A large number of our issues are already being added by the Gerrit community and by Chad. However the comment above clearly highlight an issue arising from running an almost exclusively PHP+JS shop and under adoption of FOSS development methodologies
That being said:
Using FOSS tools has a higher total cost of ownership. Managers who authorized a switch from a working system (SVN/Code review) to a new and immature systems such as Git/Gerrit - should have set aside resources (time & money) to offset the problems created by such migrations.
These generally amount to several orders of magnitude of the actual cost of the migration done by operations. The bulk of the work created by these changes are offset to the individual developers whose project will be broken by change of workflow and who might not be active. It passing strange how few of the extensions are under-maintained, unsupported.
For example: * Integration of Gerrit to our system, * Customization (adding features like better diffs) * Acceptance - getting people to change workflow and getting core developers to actually review code. * Education - Teaching established and new users to work with the Git/Gerrit, writing tutorials, training people with them at Hackatons. Updating project documentations and readmes * Secondary migration - fixing scripts/apis that depend on the current setup. E.g. my CI work in December needs to be updated to reflect using GIT/Gerrit; build scripts of systems with independent modules like search + mwdumper; updating robots and so on. * Tertiary migrations - On the developers machines. Replacing IDEs and Workspaces to reflect the Git/Gerrit workflows.
Thus switching forth between different Gerrit alternative is myopic. It ignores the friction and cost these moves create for the established developers community who have created hundreds of extensions and documented them. I say we just get consensus on the Priority Queue of outstanding Gerrit issues and start fix them until it rocks.
Oren Bochman Lead of Search
wikitech-l@lists.wikimedia.org