On Tue, Jul 24, 2012 at 10:26 PM, Erik Moeller erik@wikimedia.org wrote:
As one quick update, we're also in touch with Evan Priestley, who's no longer at Facebook and now running Phabricator as a dedicated open source project and potential business. If all goes well, Evan's going to come visit WMF sometime soon, which will be an opportunity to seriously explore whether Phabricator could be a viable long term alternative (it's probably not a near term one). Will post more details if this meeting materializes.
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.
On Monday, August 6, 2012 at 6:06 PM, Erik Moeller wrote:
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'm down. S was nearly reduced to tears (-- super manly, non-embarassing Chuck Norris tears) by Gerrit the other day, so even though he's on vacation I'm pretty confident he'd be down to try it out too. (We are the only two committers to the E3Experiments repository.)
I'd like to set this up on a third-party host so we don't add to the list of machines ops has to worry about, and so we aren't affected by labs upgrades. The monetary cost would be trivial and I don't mind shouldering it myself.
-- Ori Livneh ori@wikimedia.org
….and we're up: http://phab.256.io/
-- Ori Livneh ori@wikimedia.org
On Monday, August 6, 2012 at 7:02 PM, Ori Livneh wrote:
On Monday, August 6, 2012 at 6:06 PM, Erik Moeller wrote:
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'm down. S was nearly reduced to tears (-- super manly, non-embarassing Chuck Norris tears) by Gerrit the other day, so even though he's on vacation I'm pretty confident he'd be down to try it out too. (We are the only two committers to the E3Experiments repository.)
I'd like to set this up on a third-party host so we don't add to the list of machines ops has to worry about, and so we aren't affected by labs upgrades. The monetary cost would be trivial and I don't mind shouldering it myself.
-- Ori Livneh ori@wikimedia.org (mailto:ori@wikimedia.org)
On Mon, Aug 6, 2012 at 10:35 PM, Ori Livneh ori@wikimedia.org wrote:
….and we're up: http://phab.256.io/
Then how do people get accounts? another perfect case for OAuth (or whatever we end up implementing instead)
(I don't see an obvious way for anons to create new accounts but maybe I'm just missing it)
-Jeremy
On Mon, 06 Aug 2012 19:38:11 -0700, Jeremy Baron jeremy@tuxmachine.com wrote:
On Mon, Aug 6, 2012 at 10:35 PM, Ori Livneh ori@wikimedia.org wrote:
….and we're up: http://phab.256.io/
Then how do people get accounts? another perfect case for OAuth (or whatever we end up implementing instead)
(I don't see an obvious way for anons to create new accounts but maybe I'm just missing it)
-Jeremy
;) You just had to put review and auth -- the two projects I wish I had a contract to finish one of -- in the same email...
On Mon, Aug 6, 2012 at 7:02 PM, Ori Livneh ori@wikimedia.org wrote:
(We are the only two committers to the E3Experiments repository.)
That's a good and a bad thing as it'll likely mean we're not going to get a lot of insight into the code review benefits & drawbacks unless we get a few more people excited to work on that particular extension.
A consequence of having an extension (as opposed to something standalone like the mobile app or Limn) as the test case would be that we'll have to figure out how to make it work well with the MW deployment process - not sure how hard that would be in practice, but again something you'd have to solve without leaning too much on others.
I'd like to set this up on a third-party host so we don't add to the list of machines ops has to worry about, and so we aren't affected by labs upgrades. The monetary cost would be trivial and I don't mind shouldering it myself.
I'm not terribly fond of that idea as it sounds like a truly dead-ended approach; it'd be nice to have something that can potentially grow in number of users / maintainers, and can be more straightforwardly prepared for deployment on production servers. Labs upgrades will happen, yes, but we have to grow discipline in minimizing downtime by eating our own dogfood.
….and we're up: http://phab.256.io/
But I'll grant you that it's the fastest thing to do. :) I'd be in favor of moving it to a Labs instance when possible.
On Mon, Aug 6, 2012 at 7:39 PM, Erik Moeller erik@wikimedia.org wrote:
On Mon, Aug 6, 2012 at 7:02 PM, Ori Livneh ori@wikimedia.org wrote:
(We are the only two committers to the E3Experiments repository.)
That's a good and a bad thing as it'll likely mean we're not going to get a lot of insight into the code review benefits & drawbacks unless we get a few more people excited to work on that particular extension.
Yup.
A consequence of having an extension (as opposed to something standalone like the mobile app or Limn) as the test case would be that we'll have to figure out how to make it work well with the MW deployment process - not sure how hard that would be in practice, but again something you'd have to solve without leaning too much on others.
I'd like to set this up on a third-party host so we don't add to the list of machines ops has to worry about, and so we aren't affected by labs upgrades. The monetary cost would be trivial and I don't mind shouldering it myself.
I'm not terribly fond of that idea as it sounds like a truly dead-ended approach; it'd be nice to have something that can potentially grow in number of users / maintainers, and can be more straightforwardly prepared for deployment on production servers. Labs upgrades will happen, yes, but we have to grow discipline in minimizing downtime by eating our own dogfood.
Agree w Erik. Really doesn't prove much in terms of integration towards deployment or collaboration for our community.
….and we're up: http://phab.256.io/
But I'll grant you that it's the fastest thing to do. :) I'd be in favor of moving it to a Labs instance when possible.
+1
-Alolita
-- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Monday, August 6, 2012 at 7:39 PM, Erik Moeller wrote:
But I'll grant you that it's the fastest thing to do. :) I'd be in favor of moving it to a Labs instance when possible.
Mark Traceur and I are working on a puppet manifest for labs
-- Ori Livneh ori@wikimedia.org
On Aug 6, 2012, at 7:39 PM, Erik Moeller erik@wikimedia.org wrote:
On Mon, Aug 6, 2012 at 7:02 PM, Ori Livneh ori@wikimedia.org wrote:
(We are the only two committers to the E3Experiments repository.)
That's a good and a bad thing as it'll likely mean we're not going to get a lot of insight into the code review benefits & drawbacks unless we get a few more people excited to work on that particular extension.
A consequence of having an extension (as opposed to something standalone like the mobile app or Limn) as the test case would be that we'll have to figure out how to make it work well with the MW deployment process - not sure how hard that would be in practice, but again something you'd have to solve without leaning too much on others.
When I talked to Ori, the idea here was not to set up in E3Experiments in lieu of other setups, but in addition to them.
The reality of anything that gets deployed on cluster is that the repository would have to be managed in gerrit. This means that the targets (until a decision is made) are to use phabricator on:
1) do extension that is in deploy but then gate on merge into gerrit. 2) do experimental extensions that aren't in deploy 3) do a project that isn't in gerrit/deploy train.
Ori's falls into the first. I have a number of projects that might fit into that in Features, so I can ask around, but this is actually extra work (currently) for whoever acts as the gate. Ori seems willing to for E3Experiments :-)
As for (2), the only project that could do this would be Flow which has no code written. My guess is the decision would be made before we get to the point where we're developing Flow in earnest.
As for (3), I think mobile would be the best candidate and Brion would proceed with that.
The work Ori is doing can be used to host more than just E3Experiments. ;-)
….and we're up: http://phab.256.io/
But I'll grant you that it's the fastest thing to do. :) I'd be in favor of moving it to a Labs instance when possible.
And when they do, we could try oth
On Aug 6, 2012, at 7:39 PM, Erik Moeller erik@wikimedia.org wrote:
A consequence of having an extension (as opposed to something standalone like the mobile app or Limn)
^^^^^^ Just for fun, the labs instance now tracks those repositories on GitHub
https://phabricator.wmflabs.org/diffusion/WLM/ and https://phabricator.wmflabs.org/diffusion/LIMN/
wikitech-l@lists.wikimedia.org