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