On Tue, Jul 24, 2012 at 10:26 PM, Erik Moeller <erik(a)wikimedia.org> wrote: We had this conversation with Evan today. The following people participated: David Schoonover, Brion Vibber, Rob Lanphier, Chad Horohoe, Terry Chay, Ryan Lane, Ori Livneh, Roan Kattouw, and myself. Evan gave us a walkthrough of Phabricator's current capabilities, comparing it against the evaluation criteria on https://www.mediawiki.org/wiki/Git/Gerrit_evaluation . Some thoughts below; if you participated, please feel free to jump in with your thoughts/impressions from the conversation, and/or to contradict anything I'm saying. :-) As I understood it, the big gotchas for Phabricator adoption are that Phabricator doesn't manage repositories - it knows how to poll a Git repo, but it doesn't have per-repo access controls or even more than a shallow awareness of what a repository is; it literally shells out to git to perform its operations, e.g. poll for changes - and would still need some work to efficiently deal with hundreds of repositories, long-lived remote branches, and some of the other fun characteristics of Wikimedia's repos. Full repo management is on the roadmap, without an exact date, and Evan is very open to making tweaks and changes as needed, especially if it serves a potential flagship user like Wikimedia. My impression was that a lot of Phabricator's features were well-received, including the code review / inline commenting UI tself, its much more flexible code commenting system, the simple notification filters, etc. Brion suggested in the conversation that a logical way to explore Phabricator's potential value for us might be to start using it for one of the more experimental repos. This would enable us to give feedback to Evan about what's working / what's not working, and to build a working relationship with the Phabricator community. If we believe in the potential, and the dealbreaker features are indeed forthcoming, we could then consider more seriously a move away from Gerrit down the road. If we hate it, the "only" cost is the cost to that team of setting up, maintaining and then ramping down some experimental infrastructure. (This would _not_ be a project for Rob's group to shoulder - you'd have to do so yourself.) If so, based on this, I'm wondering if there are any champions who are willing to do the legwork to 1) set up Phabricator for a current WMF engineering project, 2) convince their team (and potentially the rest of the world) to start using it? I suspect that good candidates would be projects that currently live entirely on GitHub, where Phabricator would be a step _towards_ self-hosted OSS infrastructure, as opposed to spinning out something from Gerrit. But I'd be concerned about doing this with more than one project initially, and only if the entire team is convinced that it's the right thing to do, and is willing to somewhat slow down its velocity to do so. Obviously, any volunteer who wants to experiment with it for their Wikimedia-related project would be welcome to do so in Labs, as well, and I'd be happy to connect them w/ Evan if needed. The alternative is to take another look at Phabricator only when it more closely matches our must-have requirements. -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate