== 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)